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EXECUTIVE  SUMMARY 


Background 

Multi'hop  High  Frequency  (HF)  (2  to  30  MHz)  networks  are  presently  being  developed  as  a  solu¬ 
tion  to  the  problem  of  communication  in  the  Intra  B^e  Group  (IBG)  environment  In  the  case  of  net¬ 
works  such  as  the  one  proposed  in  [ES.  1].  a  single  frequency  is  shared  among  all  the  nodes  in  the  network. 
HF  communications  are  subject  to  many  time-varying  effects  such  as  Battle  Group  platform  motion,  day/ 
night  channel  effects,  changing  sea  state  conditions,  frequency  versus  communication  range  capability, 
jamming,  and  dynamic  noise  environments.  These  conditions  all  contribute  to  making  it  difficult  to  find  a 
single,  “best"  fr^uency  for  network  operation.  Standardized  Automatic  Link  Establishment  (ALE)  tech- 
niques[ES.2]  provide  good  frequency  selection  for  a  single  link  but  they  ate  often  slow  and  do  not  answer 
the  question  of  what  is  the  optimum  frequency  choice  for  an  entire  network. 

This  report  focuses  on  the  design,  development,  and  testing  of  a  prototype  Network  Frequency 
Selection  Service  (NFSS)  that  would  automate  tlw  selection  of  a  single,  best  frequency  for  operation  of  a 
single-channel  network.  For  the  intended  s^jplication,  the  communicating  platforms  are  generally  dis¬ 
persed  over  an  area  less  than  3(X)  nm  across.  Communication  in  this  scenario  is  usually  achieved  by  HF 
groundwave,  although  some  skywave  propagation  is  possible.  Selection  of  an  HF  operating  frequency  for 
the  network  could  be  decided  prior  to  starting  up  tte  network  and  made  part  of  the  communications  plan. 
However,  problems  can  arise  if  the  pre-selected  operating  frequency  results  in  poor  communication  perfor¬ 
mance,  unless  there  is  some  method  for  switching  to  a  more  suitable  frequency.  Tlie  NFSS  provides  an 
automated  procedure  for  selecting,  from  a  given  sequential  collection  of  HF  frequencies,  the  “best"  fre¬ 
quency  for  use  by  the  network.  After  selecting  the  operating  frequency,  the  NFSS  proceeds  to  set  the  client 
network’s  transmitter  and  receiver  to  the  chosen  fre^ency.  The  functions  of  the  NFSS  are  inq)lemented  in 
software  to  perform  this  service. 

Development  of  a  Prototype  of  a  Network  Frequency  Selection  Service 

The  NFSS  is  intended  to  be  used  as  a  schnluled  service,  lluit  is,  it  begins  and  ends  operation  at 
I»edetermined  times.  During  the  periods  when  the  NFSS  is  active  it  normally  tests  a  subset  of  the  candi¬ 
date  frequencies  along  with  the  previously  chosen  best  frequency,  and  chooses  the  new  best  frequency 
from  among  this  subset.  Eventually,  over  several  such  active  periods,  all  candidate  frequencies  are  tested. 
The  client  network  operates  in  its  normal  manner  between  activations  of  the  NFSS. 

In  the  prototype  NFSS,  the  “best”  fiequency  is  the  one  that  minimizes  the  frequency  selection  met¬ 
ric  shown  in  figure  ES-1  (Metric  B).  The  metric  is  ^wn  here  in  the  form  of  an  integer  expressed  in  binary 
format  The  most  significant  bit  is  on  the  left  The  “best”  frequency  is  the  one  that  minimizes  this  integer. 
Thus,  the  most  important  factor  in  this  metric  is  tiie  number  of  unconnected  nodes,  nodes  that  are  dis¬ 

connected  from  the  largest  component  of  the  network.  This  implementation  attempts  to  choose  the  fi:e- 
quency  that  leaves  the  fewest  n^s  disconnected  ftom  the  largest  component  of  tiie  network.  If  several 
frequencies  result  in  the  same  number  of  unconnected  nodes,  the  best  frequency  is  the  one  that  requires  the 
fewest  number  of  relay  nodes  on  the  backbone  netwOTk.  This  will  maximize  performance  of  a  network  that 
must  operate  on  a  single  frequency[ES.3].  The  field  “Number  of  Uncotmected  Links  (NUL)”  is  tiie  third 
most  important  consideration  in  selecting  tiie  best  operating  finquency.  NUL  is  N*(N-l)/2  minus  the 
known  number  of  bidirectional  links  in  the  netwmk.  Thus,  NUL  represents  the  number  of  links  tiutt  the 
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given  topology  falls  short  of  being  a  hilly  connected  network.  Finally,  the  least  signihcant  component  in 
the  frequency  selection  metric  is  the  index  of  the  frequency  in  the  sequential  collection  of  candidate  fre¬ 
quencies 
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Sample  Outputs  from  the  Network  Frequency  Selection  Service 

Figures  ES-2  through  ES-?  show  sample  outputs  from  the  Network  Frequency  Selection  Service 
for  a  7-node  simulation  model  with  one  mobile  node  (node  7),  which  traversed  a  prc-spedfied,  determinis¬ 
tic  path  through  the  remaining  nodes.  There  were  a  total  of  12  frequencies  tested;  friey  are  shown  in  table 
ES- 1 .  Frequencies  were  tested  in  groups  (NFSS  test  cycles)  of  four  frequencies.  Ihe  first  three  frequencies 
in  each  N^S  test  cycle  were  taken  (in  round-robin  f^on)  from  the  t^le  of  candidate  frequencies.  The 
fourth  frequency  was  taken  as  the  best  frequency  fi:om  the  {nevious  test  cycle.  A  “frequency  test  cycle” 
corresponds  to  a  test  of  a  single  frequency.  For  tte  simulation  tests,  the  Nf^S  test  cycles  were  run  contigu¬ 
ously.  NonnaUy,  however,  the  NFSS  test  cycles  would  be  separated  by  periods  when  the  client  network 
would  be  operational. 

Each  figure  displays  two  NFSS  test  cycles,  and  each  panel  in  figures  ES-2  through  ES-7  disfdays 
results  for  one  frequency  test  cycle.  The  time-ordaing  of  results  is  from  top  to  bottom  of  the  first  column 
followed  by  the  same  ordering  in  the  second  column.  Each  panel  shows  the  following  information;  an 
NFSS  frequency  test  cycle  identifier,  the  bidirectional  links  for  that  frequency  test  cycle,  the  value  of  the 
metric  (in  hexadecimal  notation),  the  test  frequency  (in  MHz),  and  the  time  at  whidi  the  frequency  test 
cycle  began  (in  simulated  hrs:min:sec.ms).  Fm  this  example,  the  NFSS  test  cycle  is  approximately  100 
seconds  duration. 

For  the  simulation  model,  frequency  12.03  MHz  has  the  greatest  communication  range  (IIS  km). 
The  results  show  that  this  frequency  is  eventually  chosen  as  the  best  frequency.  The  results  also  illustrate 
how  the  values  of  the  metric  change  as  platform  7  moves,  lb  see  what  these  metrics  mean,  we  decode  and 
compare  the  metric  values  0x30282  and  0x230401,  nliidi  appear  in  panels  marked  Nfss  Tests  9.3  and  9.2, 
re^)ectively,  of  figure  ES-6.  We  write  0x30282  (after  padding  on  die  left  to  extend  the  result  to  the  26  bits 
retpiired  by  the  metric)  -  (X)  (XXX)  001 1  (XXX)  (X)10 1(X)0  0010  (binary),  which  we  group  into  the  fields  of 
our  metric  as  follows:  -  00000,  Ni,^  =  00011,  NUL  s  0000001010,  F,^  =  000010.  In  tmms  of  ded- 
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mal  integers,  the  metric  value  0x30282  represents  the  situation  where  all  nodes  are  connected  =  0), 
three  relay  nodes  (nodes  3, 5.  and  6)  are  required  =  3),  the  network  is  10  links  shy  of  being  fully  con¬ 
nected  (NUL  =  10),  and  the  frequency  index  is  2  (f  =  2),  which  means  that  the  test  frequency  is  12030 
kHz.  For  the  metric  value  0x230401.  we  get  0x230401  =  00  0010  0011  0000  0100  0000  0001.  This 
decodes  to  the  following:  =  00001,  N^i,  =  00011,  NUL  =  0000010000,  =  000001.  Thus,  in  terms 

of  decimal  integers,  the  metric  value  0x230401  represents  the  situation  where  one  node  (node  5)  is  discon¬ 
nected  from  the  main  body  (n„„<.  =  1).  three  relay  nottes  (nodes  3. 5,  and  6)  are  required  (^^^  =  3).  the 
network  is  16  links  shy  of  being  fully  connected  (NUL  =  16),  and  the  frequency  index  is  1  (F,^  =  1), 
which  means  that  the  test  frequency  is  1 1062.5  kHz. 

Table  ES-1:  Frequencies,  channel  noise  levels,  and  communication  ranges  for  test  7NFSE- 

T3. 


Freq.  Array 
Index 

Freq.  (Khz) 

Channel 
Noise  (db) 

Range^ 

(Km) 

0 

10680.0 

-100.0 

37.97 

1 

11062.5 

-115.0 

81.72 

2 

12030.0 

-135.0 

115.38 

3 

12673.5 

-125.0 

109.59 

4 

13238.5 

-110.0 

50.0 

5 

13980.0 

-125.0 

98.6 

6 

14695.0 

-105.0 

36.6 

7 

16923.0 

-135.0 

77.35 

8 

16954.0 

-120.0 

60.35 

9 

17514.0 

-125.0 

73.57 

10 

18556.0 

-130.0 

67.22 

11 

20025.0 

-110.0 

29.75 

a.  Range  is  based  on  the  noise  at  the  receiver,  which  is  approx¬ 
imated  as  the  larger  of  the  channel  noise  (see  coluirm  3)  and  the 
receiver  ix)ise  (-125  db). 


Conclusions 

This  report  describes  a  prototype  Network  Frequency  Selection  Service.  The  NFSS  can  be  used  as 
a  stand  alone  system  ot  it  can  be  used  to  find  the  best  operating  frequency  for  a  client  network.  As  a  stand 
alone  system  the  NFSS  can  be  used  to  monitor  and  evaluate  the  suitability  of  various  HF  channels  for  use 
in  intiatask  force  communication  networks.  Results  of  these  tests  could  be  analyzed  manually  to  selea  the 
operational  frequency  for  an  intratask  force  network.  Alternatively,  the  NFSS  can  be  integrated  widi  a  cli¬ 
ent  network  so  that  the  NFSS  periodically  tests  a  set  of  frequencies  and  automatically  sets  die  transmitter/ 
receiver  to  the  best  frequency  for  that  network.  Extensions  of  this  work  to  cover  the  selection  of  multiple 
frequencies  in  multi-channel  networks,  such  as  those  described  in  [ES.31  to  [ES.5]  are  suggested. 
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DESIGN,  DEVELOPMENT,  AND  TESTING  OF  A 
NETWORK  FREQUENCY  SELECTION  SERVICE  (NFSS) 


1.  INTRODUCTION 

Hie  Naval  Research  Laboratory  (NRL)  has  proposed  the  develoiwient  of  a  Network  Frequency 
Selection  Expetiment  (NFSE)  as  part  of  the  Naval  Command  Control  and  Ocean  Surveillance  Center  • 
Naval  Research  and  Development’s  (NCCOSC-NRaD)  6.2  Communications  and  Networking  block.  The 
objective  of  the  NFSE  is  to  demonstrate  the  caps^lity  of  a  High  Frequency  (HF)  Intra  Battle  Group  (IBG) 
communication  network  to  automatically  adapt  its  operating  frequency  to  the  best  choice  from  a  pool  of 
candidate  operating  frequencies.  HF  (2  to  30  MHz)  communications  ate  subject  to  many  time-varying 
effects  such  as  Battle  Group  platform  motion,  day/night  channel  effects,  changing  sea  state  conditions,  fre¬ 
quency  versusxommunication  range  capability,  jamming,  and  dynamic  noise  environments.  These  condi¬ 
tions  ^1  contribute  to  making  it  difficult  to  find  a  single,  “best”  frequency  for  network  operation. 
Standardized  Automatic  Link  Establishment  (ALE)  techniques  [2]  provide  good  frequency  selection  for  a 
single  link  but  do  not  answer  the  question  of  what  is  the  optimum  frequency  choice  for  an  entire  network. 

NRL  has  proposed  to  implement  an  automated  Network  Frequency  Selection  Service  (NFSS)  by 
enhancing  the  network  control  algorithms  developed  artd  successfully  tested  in  the  Unified  Networking 
Technology  (UNT)  project  [3]  [4].  This  technology  shall  be  demonstrated  using  the  various  nodes  at  the 
NCCOSC-NRaD  UNT  testbed.  Since  NRL’s  networking  algorithms  were  successfully  demonstrated  dur¬ 
ing  the  September  1990  UNT  tests,  our  modifications  of  that  design  to  inq>lement  a  frequency  selection 
service  should  not  be  a  major  risk  item.  Once  the  techniques  for  automated  selection  of  a  netwide  operat¬ 
ing  frequency  have  been  successfully  demonstrated,  the  algorithms  can  be  incorporated  into  other  systems, 
such  as  NCCOSC-NRaD’s  own  MINCAP  system. 


2.  ORGANIZATION  OF  REPORT 

This  report  contains  the  documentation  needed  to  guide  the  developmem  of  all  software  for  the 
Network  Frequency  Selection  Expetiment,  which,  hereafter,  is  called  the  “NFSE  System".  This  documen¬ 
tation  loosely  follows  the  software  documentation  requirements  mandated  by  DOD-STD-2167A  for  soft¬ 
ware  developtnent[6].  Section  3  lists  applicable  documents.  Section  4  defines  acronyms,  symbols,  special 
terms,  and  software  constants  used  in  this  report  Sections  5  through  11  are  organized  so  that  each  major 
section  covers  a  key  Data  Item  Description  (DID)  of  the  2167A  standard.  Huis,  section  5  corresponds  to 
the  System  Spedfication  for  the  NFSE  system.  Section  6  corresponds  to  the  System  Design  Document 
Section  7  comains  the  Software  Development  Plaa  Section  8  corresponds  to  a  Software  Requirements 
Document  for  each  Computer  Software  Configuration  Item  (CSCI)-  Section  9  corresponds  to  an  Interface 
Requirement  Spedfication  for  interconnecting  CSCIs.  Section  10  provides  the  equivalent  of  a  Software 
Design  Document  for  each  CSCI;  and  section  11  corresponds  to  an  Interface  Design  Document  for  eadi 
CSCI.  Sections  12, 13,  and  14  cover  the  in-lab  test  plans,  descriptions,  and  results,  respectively. 

The  information  in  this  report  is  subject  to  change,  lb  allow  for  these  changes.  Sections  4  tiuough 
11  each  end  in  a  subsection  that  is  irttended  to  contain  the  revision  history  for  that  section.  The  initial  ver¬ 
sion  of  tiiis  repmt  is  Version  1.0.  The  current  version  number  shall  always  appear  under  the  title  on  the 
report’s  title  page. 

Manuscript  approved  December  10, 1993. 
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4.  DEFINITIONS 

4.1  Acronyms  ai^  Abbreviations 


Table  1:  Meanings  of  acronyms  and  abbreviations 


Acronym/ 

Abbreviation 

Meaning 

ALE 

Automatic  Link  Establishment 

ASAP 

As  Soon  As  Possible 

BLC 

Black  Link  Controller 

COTS 

Commercial,  off-the-shelf 

CSC 

Computer  Software  Component 

CSCI 

Computer  Software  Configuration  Item 

CSS 

Communications  Support  System 

CSU 

Computer  Software  Unit 

DID 

Data  Item  Description 

DOD-STD 

Department  of  Defense  Standard 

DRAM 

Dynamic  Random  Access  Memory 

DSPT 

Distributed  Simulation  and  Prototyping  Testbed 

EBB 

Enhanced  biu:kbone  Network 

GMT 

Greenwich  Mean  Hme 

GPS 

Global  Positioning  System 

GUI 

Grtydiical  User  Interface 

HAMA 

HaiKlofr  Assigned  Multiple  Access 

HF 

High  Frequency 

HW 

Hardware 

IBG 

Intiabattie  Gtoiq) 

Table  1:  Meanings  of  acronyms  and  abbreviations 


Acronym/ 

Abbreviation 

Meaning 

IP 

Internetwork  Protocol 

IRS 

Interface  Requirements  Specification 

ISO 

International  Organization  for  Standardization 

KG 

Key  Generator 

LCA 

Linked  Cluster  Architecture  or  Linked  Cluster  Algorithm 

LSB 

Least  Significant  Bit 

MHz 

Megahertz 

MIL-STD 

Military  Standard 

MINCAP 

Minimum  Coverage  Approximation 

MSB 

Most  Significant  Bit 

mo 

month 

ms 

milliseconds 

NCCOSC- 

NRaD 

Naval  Command  Control  and  Ocean  Surveillance  Center  •  Naval  Research  and 
Development  (formerly  NOSC) 

NFSE 

Network  Frequency  Selection  Experiment 

NOSC 

Naval  Ocean  Systems  Center  (ik>w  NCCOSC-NRaD) 

NRL 

Naval  Research  Laboratory 

n.a. 

not  applicable 

nm 

nautical  miles 

ONT 

Office  of  Naval  Ibchnology 

OOD 

Object  oriented  design 

OOP 

Objea  oriented  programming 

PDM 

Projea  Design  Manual 

PLM 

Project  Listings  Manual 

ppm 

Pulse  per  millisecond 

Qty. 

(Quantity 

RB 

Reliable  Bidirectional 

RCS 

Revision  Control  System 

Table  1:  Meanings  of  acronyms  and  abbreviations 


Acronym/ 

Abbreviation 

Meaning 

RCVR 

Receiver 

RF 

Radio  Frequency 

RLC 

Red  Link  Controller 

SAINT 

Shared  Adaptive  Internetworking  Technology 

SDD 

Software  Design  Document 

SDF 

Software  Development  Files 

SDL 

Software  Development  Library 

SDP 

Software  Development  Plan 

SRS 

Software  Requirements  Specification 

SSDD 

System/Segment  Design  Document 

SSS 

System/Segment  Specification 

STD 

Software  Test  Descriptions 

SW 

Software 

s 

seconds 

T/R 

TVansmit/Receive 

TBD 

To  Be  Determined 

UNT 

Unified  Networking  Technology 

XMTR 

liransmitter 

yr 

year 

4.2  Identifiers  Used  to  Describe  System 

Table  2:  CSCI  Identifiers 


Identifier 

Long  Name 

NC 

Network  Controller 

LC 

LinkConnoUer 

SC 

System  Controller 
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Table  3:  CSC  Identifiers 


Identifiers 

Long  Name 

Parent 

CSCI 

LC_BIOS 

Basic  Input  Output  System 

LC 

LC.OS 

LC  Operating  System 

LC 

LC_TC 

LC  llmiiig  Control 

LC 

Nc.cx: 

Congestion  Control 

NC 

NC_IP_CONN 

Internet  Protocol  Connection 

NC 

NC_LC_CONN 

Link  Controller  Connection 

NC 

NC.MR 

Message  Router 

NC 

NC_NCL 

Network  Connectivity  Learning 

NC 

NC.NFSS 

Network  Frequency  Selection  Service 

NC 

NC_NM 

Network  Manager 

NC 

NC_NRT_SU 

Startup  for  NC_NRT  Processor 

NC 

NC.NS 

Network  Structuring 

NC 

NC.RBM 

Receive-Buffers  Management 

NC 

NC„RC 

Receiver  Control 

NC 

NC_RTO_CL 

Real-time  Output  Client 

NC 

NC.RTO.SV 

Real-time  Ouqmt  Server 

NC 

NC_SRC_SNK 

IVaffic  SouFce/Sink  (for  simulated  user-traffic) 

NC 

NC.TBM 

Ihuismit-Buffers  Management 

NC 

NC_TC 

NC  Timing  Control 

NC 

NC_XC 

Thmsmitter  Control 

NC 

Table  4:  CSU  Identifiers 


Identifier 

Long  Name 

Parent  CSC 

BTRA 

Broadcast  TkafBc  Routing  Algmithm 

CCA 

Congestion  Control  Algorithm 

NC.CC 

LCA 

Linked  Cluster  Algtxitiun 

NC_NS 

Table  4:  CSU  Identifiers 


Identifier 

Long  Nante 

Parent  CSC 

NCLA 

Network  Connectivity  Learning  Algorithm 

NC.NCL 

NFSA 

Network  Frequency  Selection  Algmittun 

NC_NFSS 

NSMA 

Network  Status  Monitoring  Algorithm 

NC_NM 

P2PRA 

Point-to-Point  Routing  Algorithm 

NC_MR 

PPA 

Periodic  Probing  Algorithm 

NC_NCL 

RBMA 

Receive-Buifers  Management  Algorithm 

NC_RBM 

RSA 

Receiver  Scheduling  Algorithm 

NC_RC 

TBMA 

IVansmit  Buffers  Management  Algorithm 

NC_TBM 

TSA 

Transmission  Scheduling  Algorithm 

NC_XC 

Table  5:  Interface  Identifiers 


Identifier 

Long  Name 

Components  Linked 

IF_LC_GPS 

LC/GPS  Interface 

LC 

GPS 

IF_LC_LC 

LC  Peer-Level  Interface 

LC 

LC 

IF_LC_NOSC 

LC/NOSC  BLC  Interface 

LC 

NOSC  BLC 

IF_LC_RCTL 

LC/Receiver  Control  Interface 

LC 

Receiver 

IF_LC_XCTL 

LC/Transmitter  Control  Interface 

LC 

Transmitter 

IF_NC_LC 

NC/LC  Interface 

NC 

LC 

IF.NC.NC 

NC  Peer-Level  Interface 

NC 

NC 

IF_OP_SC 

Operator/sc  Interface 

Operator 

SC 

IF_SC_LC 

SC/LC  Interface 

SC 

LC 

IF_SC_NC 

SC/NC  Interface 

SC 

NC 

Table  6:  VME-Board  Identifiers 


Identifier 

Long  Name 

LANCNTR 

Ethernet  Controller  Board  (ENP-IOL) 

M224NRL 

NRL’s  MVME224A-1  Memory  Board 

Table  6:  VME*Board  Identifiers 


Identifier 

Long  Name 

M333NRL 

NRL’s  MVME333*2  Processor  Board 

M333NRaD 

NRaD's  MVME333-2  Processor  Board 

NC_NRT 

NC  Non-Real-lime  Processor  Board  (MVME135A) 

NC.RT 

NC  Real-time  Processor  Board  (MVME135A) 

Proc#n 

Processor  #n  (n  is  the  vx Works-assigned  #) 

Table  7:  Names  of  System  Capabilities 


Identifier 

Long  Name 

IN.CAP 

Internal  Network  Capability 

MCA.CAP 

System  Monitor,  Controller,  and  Archiver 

NC_COM 

ND.TTME 

NodeHming 

NFSS 

Network  Frequency  Selection  Service 

SC_ARCfflVE 

System  Archiver 

SC_MONITOR 

System  Monitor 

TPD.CAP 

Test-Plan  Description  Service 

4.3  Symbols 


Table  8:  Symbols  used  in  this  document  (except  for  time-of-occurrence  symbols). 


Notation 

Page 

Meaning 

Min. 

Max. 

Units 

% 

87 

An  operator  such  that  i%j  returns  the 
remainder  of  the  division  of  i  by  j. 

n.a. 

n.a. 

H 

26 

rifa  scheduled  active  cycle  of  NFSS 

wmm 

n.a. 

n.a. 

at  U) 

87 

Function  that  returns  pointer  to  the/th 
element  of  a  sequential  collection. 

n.a. 

n.a. 

n.a. 

Psc 

18 

Sequential  collection  of  candidate  fire- 
quendes  given  as  input  to  NFSS. 

B 

fmax 

MHz 

Table  8:  Symbols  used  in  this  document  (except  for 


Meaning 


Array  of  test-frequencies  to  be  used  by 
NFSS  diuing  current  activation. 


frequency  chosen  by  the  NFSS  as  the 
“best”  frequency. 


Frequency  chosen  as  the  “best”  fre¬ 
quency  during  the  ith  active  cycle  of 
the  NFSS. 


Maximum  value  for  frequencies  in  the 
collection 


Minimum  value  for  frequencies  in  the 
collection 


Sequential  collection  of  candidate  fre¬ 
quencies  given  as  input  to  NFSS. 


(Link  (Quality  Index)  -  measure  of  the 
quality  of  link  from  node  j  to  node  i 


Threshold  value  for  classifying  a  link 
as  unreliable  or  reliable 


Number  of  elements  in  array  /aQ 


Number  of  nodes  in  client  network 


Number  of  frames  in  all  but  the  last 
NFSS  frequency  test  cycle  F  • 


Maximum  value  of  N 


NFSS  frequency  test  cycle  j  (using  fre¬ 
quency  stored  in/a[/] 


Number  of  elements  in  the  collection 


Denotes  a  duration 


The  duration  over  which  the  NFSS  is 
active. 


Period  between  start  of  successive, 
scheduled  active  cycles  of  the  NFSS 


Duration  over  vdiich  the  NFSS  is  test¬ 
ing  with  die  frequency  in  fa  \J\ 


Remganization  period  for  internal  net¬ 
work 


Table  8:  Symbols  used  in  this  document  (except  for  time-of*occurrence  symbols). 


Notation 

Page 

Meaning 

Min. 

Max. 

Units 

^fiti 

See  figure  19. 

0 

TBD 

ms 

^sud 

16 

Minimum  delay  from  NFSE  System 
startup  until 

0 

TBD 

ms 

t 

15 

Denotes  a  time-of-occuirence,  refer¬ 
enced  to  some  point  in  time. 

0 

TBD 

i 

15 

Denotes  a  time-of-occurrence.  refer¬ 
enced  to  calendar  time. 

unspec 

un^dfied 

day:m 

o:yrm 

s 

Table  9:  Time-of>occurrence  symbols  used  in  this  document 


Notation 

Page 

Meaning 

Ref.  to 

Units 

h 

15 

Calendar-lime  reference  for  die  system 

calendar 

day;mo:yr 

_ 

26 

Start  of  frequency  test  cycle  P, 

^a,l 

ms 

Ui 

17 

ith  scheduled  active  cycle  for  the  NFSS. 

h 

ms 

^a,l 

Start  of  last  (most  recent)  active  cycle  of  NFSS 

h 

ms 

^a,s 

16 

Start  of  first  active  cycle  of  NFSS 

*0 

ms 

% 

.26 

Time  of  computation  of  frequency  selection 
metric 

*  J 

ms 

16 

System-referenced-time  that  system  startup 
occurs 

h 

ms 

15 

Calendar-time  that  system  startup  occurs 

calendar 

day.moiyr: 

ms 

Table  10:  Software  constants. 


Name  of  Constant 

Value 

cca_epcx:hs_betweenjnits 

2 

CCA_MAX_NUM_CL_SCHEDS_REPORTED 

5 

CCAJNIT_GLOBAL_FACTOR 

1.0 

F_MAX 

30.0  MHz 
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Table  10:  Software  constants. 


Name  of  Constant  Value 


F_MIN  2.0  MHz 


LQLRELIABLE  3 


MAX_NET_SIZE  31  nodes 


MAX_NUM_RCVRS  5  per  node 


MAX_NUM_SCHEDS_REPORTED  3 


MAX.SEQ  511 


MAX_USER_DATA  792  bits 


MSG_STORE_SZ  64  msgs 


M.BLKSIZE  22  bytes 


NB_GLB_C0NGEST10N_FACT0R  8  bits 


NB_NCLA_EPOCH  4  bits 


NB.NODEJD  5  bits 


NB_NUM_SCHEDS_REPORTED  2  bits 


NB_SINGLE_LQI  2  bits 


NB.SEQ  9  bits 


NB_SLOTS_REQUESTED  8  bits 


NB.STATUS  2  bits 


NB_TRAFnC_LIMIT_REQUESTED  5  bits 


NCLA_MAX_EPOCH 


NCLA_MAX_EPOCHS_BETWEEN_RETRANSMISSIONS  20 


NUM_FRAMES_PER_EPOCH 


RAMP  0.1 


swrrcH  1.04 


4.4  Terms 


Table  11:  Terms  defined  in  this  document 


Term  Meaning 


Calendar  time 

GMT,  as  might  be  obtained  with  a  GPS  receiver 

Client  networic 

Network  that  uses 

the 

Network  Frequency  Selection  Service 

11 


Table  11:  Terms  defined  in  this  document 


Term 

Meaning 

Host  node 

The  node  at  which  software  is  executing. 

Mode  A 

System  mode  characterized  by  interleaved  operation  of 

NFSS  and  external  client  network. 

Mode  B 

System  mode  characterized  by  interleaved  operation  of 
b^S  and  internal  client  network. 

ModeC 

System  mode  characterized  by  concurrent  operation  of 

NI^S  and  internal  client  network. 

System  reference  time 

NFSE  System  reference  time  (0  hrs:  0  min:  0  secs  Jan.  1 , 

1970  in  our  implementation) 

4.5  Revisions  to  Section  4 

None. 


12 


5.  SYSTEM  SPECIFICATION 


This  section  serves  as  the  System/Segment  Specification  (SSS)  for  the  Network  Frequency  Selec¬ 
tion  Experiment  (NFSE)  System. 

5.1  Scope 

5.1.1  Identification 

This  system  shall  be  referred  to  as  the  Network  Frequency  Selection  Experiment  System  or  as  the 
NFSE  System. 

5.1.2  System  Overview 

This  system  shall  implement  a  field-demonstration  of  a  Network  Frequency  Selection  Service 
NFSS).  This  service  shall  periodically  test  network  connectivities  and  set  the  client  network’s  transmitter 
and  receiver  to  the  “best”  frequency  for  network  operation.  The  latter  shall  be  chosen  from  among  a  collec¬ 
tion  of  allowed  frequencies,  which  is  provided  as  input  to  the  NFSS. 

5.13  Section  Overview 

Section  S  specifies  the  requirements  for  tte  NFSE  System  and  forms  the  Functional  Baselloe  for 
that  system. 

5.2  Applicable  Documents 

See  Section  3. 

53  System  Requirements 

5.3.1  Definitions 

5.3.1.1  General  Description 

To  understand  the  NFSE  System  requirements  and  constraints,  it  is  first  necessary  to  provide  some 
background  into  how  the  UNT  tests  were  perfomKd. 

l\vo  HF  network  communication  architectures  were  field-tested  during  tte  UNT  tests.  NRL  tested 
a  multi-frequency  network  architecture  called  tte  Linked  Ouster  Architecture  (LCA)[3]  and  [4]  and 
NOSC  tested  a  single-frequency  network  architecture  based  on  the  HAMA/MINCAP  {xotocols  [5].  Both 
the  NRL  and  NOSC  HF  networks  used  the  same  set  of  modems,  transmitters,  receivers,  power  amplifiers, 
and  anteiuias.  In  addition,  both  network  controllers  were  co-resident  in  the  same  VME-dtassis,  although 
they  ran  on  separate  VME  boards  within  that  chassis.  One  major  difference  in  the  hardware  configurations 
for  the  two  networks  is  that  the  NOSC  HF  network  also  incQnxuated  a  link  encryption  device.  Hence  the 
NOSC  hardware  architecture  also  included  a  KG84  crypto,  wtudi  was  followed  by  another  VME  chassis 
in  which  they  imi^emented  their  “Black  Link  Controlled  (BLC).  In  order  for  both  NRL  and  NOSC  to  per¬ 
form  tiwir  respective  tests,  it  was  necessary  to  alternate  the  days  that  each  organization  could  use  the  UNT 
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equipment  suite.  In  addition,  a  small  amount  of  cabling  changes  had  to  be  made  each  time  a  different  group 
needed  to  use  the  UNT  equipment.  What  is  important,  from  the  standpoint  of  developing  a  network  fre¬ 
quency  selection  experiment  is  that  in  the  UNT  project.  NOSC  implemented  a  single-channel  network, 
which  could  have  benehtted  from  the  availability  of  a  network  frequency  selection  service.  On  the  other 
hand.  NRL  implemented  a  network  that  included  many  of  the  components  needed  to  construct  and  test 
such  a  service. 

5.3.1.2  Missions 

The  purpose  of  die  NFSE  System  is  to  demonstrate  a  technique  for  selecting  a  single,  “best”  oper¬ 
ating  frequency  for  an  HF  radio  network. 

5.3.1.3  Operational  Concepts 

The  NFSE  System  shaU  time-share  the  RF  transmission  assets  with  a  client  network  for  which  it  is 
providing  the  Network  Frequency  Selection  Service.  At  predetermined  time  intervals  the  NFSE  System 
will  control  the  RF  assets  of  the  client  network.  During  these  periods,  the  NFSE  System  shall  select  the 
“best"  operating  frequency  for  the  client  network.  Before  returning  control  of  the  RF  assets  back  to  the  cli¬ 
ent  network,  the  NFSE  System  shall  set  the  transmitter  and  receiver  to  operate  at  the  selected  frequency. 

5.3.1.4  System  Design  Constraints/Considerations 

The  NFE  System  shall  build  on  the  hardware  and  software  resources  and  testing  experience 
obtained  during  the  UNT  tests.  The  advantages  of  this  approach  are  the  following:  1)  NRL’s  UNT  network 
already  implements  most  of  the  components  needed  to  support  a  Network  Frequency  Selection  Service,  2) 
this  approach  re-uses  large  amounts  of  UNT  hardware  and  software  that  has  been  field-tested,  3)  it  mini¬ 
mizes  system  integration  costs,  and  4)  it  takes  advantage  of  software  developed  for  archiving  test  results, 
duplicating  test  results  in  the  laboratory,  and  performing  additional  (post-field-test)  testing  in  the  labora¬ 
tory. 

5.3.1.5  System  Diagranis 

Rgure  1  shows  the  planned  node  hardware  architecture  in  which  the  NFSE  System  is  to  be  embed¬ 
ded.  The  major  change  from  the  UNT  node  architecture  is  to  move  the  NRL  Network  Controller  (NC)  and 
Link  Controller  (LC)  hardware  and  software  from  the  RLC  chassis  to  the  BLC  chassis  and  to  connect  the 
LC  to  the  RF  strings  via  the  NOSC  UNT  hardware/software  interfaces.  It  is  also  necessary  to  supplement 
the  UNT  design  with  an  additional  port  for  controlling  the  radio  frequency  of  the  transmitter.  Also,  an  eth- 
emet  controller  board  must  be  added  to  the  BLC  so  that  a  Sun  workstation  can  be  attached  to  the  BLC. 
This  workstation  provides  a  storage  medium  for  test  results  and  also  serves  as  a  monitor  and  controller  for 
the  system. 

Figure  4  is  a  context  diagram  for  the  NFSE  System. 

5  J.1.6  Some  Notational  Conventions 

Here  and  throughout  the  remainder  of  this  document,  we  frequently  need  to  talk  about  the  time-of-occur- 
lence  of  various  events,  lb  faciiitatp-  these  discussions  we  define  what  we  OKan  by  calendar-time  and  sys¬ 
tem-reference-time.  Calendar^time,  for  the  purposes  of  this  p^xr,  is  Greenwich  Mean  Time  (GMT)  such 
as  might  be  obtained  from  a  GPS  receiver.  System-rrference-time  is  a  value  of  calendar-time  fiiat  serves  as 
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Hgure  1  Node  hardware  arcfaitecture  in  whidi  the  NFSE  System  is  to  be  embedded, 
a  basic  time  reference  for  the  NFSE  System;  it  is  denoted  by  Iq. 

We  use  die  convention  of  reserving  lower  case  t  to  refer  to  the  time-of-occuiience  measured  widi 
reflect  to  some  reference  time,  which  is  either  expressly  stated  or  should  be  obvious  from  the  context 
When  we  wi^  to  talk  about  time-of-oocunenoe  in  calendar-time,  we  shall  use  a  "bar”  over  the  r  as  in  r. 
Hnally,  when  we  ate  interested  only  in  expressing  a  duration  of  time,  we  shall  use  an  iqiper  case  T. 

Ihe  system  requires  that  the  system  stara^)  time  r„  must  occur  after  the  system  reference  time  tg. 
Thus,  die  following  must  hold. 


IS 


Hgure  2  NFSE  System  context  diagrtm. 


to<tsu  (EQ6) 

We  also  define  as  the  number  of  nodes  in  the  client  network. 

5.3JS  Characteristics 

When  the  NFSE  System  software  is  started  at  time  it  should  compute  the  next  available  time 
tg  ^  for  which  the  NFSS  shall  be  active,  ^  shall  fall  on  time  boundaries  as  specified  in  Section 
5.3.2.1. 1.1.2.  In  addition,  the  implementation  shall  ^dfy  the  time  whi^  is  the  minimum  allowed 
delay  from  system  startup  until  Thus,  the  system  imposes  the  following  constraint 

^su  "^sud 

The  system  shall  have  three  operating  modes,  which  define  different  ways  in  udiich  the  Networic 
Frequency  Selection  Service  can  be  exercised.These  options  are  shown  in  figure  3.  The  mode  of  operation 
shall  be  determined  at  system  initialization  by  readii^  a  startup  file.  The  mode  of  operation  shall 
changeable  only  by  restarting  the  system  widi  a  differem  mode  selected.  These  modes  are  defined  as  fol¬ 
lows. 


Mode  A  -  In  this  mode  of  operation  the  NFSS  and  HAMA/MINCAP  network  time-share  the  RF 
communication  assets.  When  the  NI^S  has  control  of  the  RF  assets  it  performs  those  tasks  needed  to  select 
the  “best”  operating  fiequency.  At  the  end  of  its  duration  of  control,  the  NFSS  sets  the  transmitter  to  the 
new  operating  frequency.  Then  the  HAMA/MINCAP  network  operates  in  its  normal  fashion  using  this 
operating  frequency  until  it  is  time  to  repeat  the  cycle. 

Mode  B  -  This  is  identical  to  Mode  A  with  the  exception  that  the  NFSE  uses  (optional)  its  own, 
internal  network  communication  protocols  instead  of  die  HAMA/MINCAP  protocols.lhis  mode,  without 
the  optional  activation  of  the  internal  network  is  used  if  one  is  solely  interest  in  exercising  the  NFS»S. 
The  use  or  non-use  of  the  internal  network  in  this  mode  of  operation  shall  be  determined  at  system  initial¬ 
ization  by  reading  a  startup  file. 

Mode  C  -  This  is  identical  to  Mode  B  widi  the  exception  that,  if  the  internal  network  is  activated, 
network  communication  does  not  cease  operation  while  the  NFSS  is  (iterating. 
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Legend 

Select  new  (^)enting  frequency 

User  Communication  via  external  HAMA/  MINCAP  netwwk 


User  Communication  via  internal  nttwork 


Mode  C 


^a.U+l) 


Figure  3  Modes  of  NFSE  System  operstioa:  Mode  A  •  Interleaved  opeiation  of  NFSS  and  HAMA/MINCAP  network:  Mode 
B  -  Interleaved  operation  of  NFSS  and  internal  netwmk:  Mode  C  •  Concurrent  operation  of  NFSS  and  internal  network. 


5J.2.1  Performance  Characteristics 

This  subsection  specifies  the  NFSE  System’s  capabilities  in  the  context  of  the  modes  in  whidi  the 
system  can  exist 

SjyLlA  Mode  A 

Nfode  A  interleaves  the  operation  of  die  Nl^  with  diat  of  an  external  networic,  such  as  a  HAMA/ 
MINCAP  network.  [5] 
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Networii  Frequency  Selection  Service  (NFSS) 

5.3J.1.1.1.1  Informal  Description 

The  intended  application  of  the  NFSS  capability  is  a  single-frequency.  HF  radio  network  for  an 
intratask  force.  An  example  of  such  a  network  is  the  HAMA/MINCAP  network,  which  was  demonstrated 
in  the  UNT  tests.  [S]  For  the  intended  application  the  communicating  platforms  are  generally  dispersed 
over  an  area  less  than  300  nm  across.  Communication  in  this  scenario  is  usually  achieved  by  HF  ground- 
waves.  although  some  skywave  propagation  is  possible.  Selection  of  an  HF  operating  frequency  for  tiie 
network  could  be  decided  imor  to  starting  up  the  network  and  made  part  of  the  communications  plait 
However,  problems  can  arise  if  the  pre-selected  operating  frequency  results  in  poor  communication  perfor¬ 
mance,  unless  there  is  some  method  for  switching  to  a  more  suitable  frequency.  The  NFSS  provides  an 
automated  procedure  for  selecting,  from  a  given  sequential  collection^  of  HF  frequencies,  tiie  “best"  fre¬ 
quency  for  use-by  the  netwwk.  After  selecting  tlK  operating  frequency,  the  NFSS  proceeds  to  set  the  client 
network  node’s  transmitter  and  receiver  to  the  chosen  frequency.  The  functions  of  the  NFSS  are  imple¬ 
mented  in  software  to  perform  this  service.  The  NFSS  is  intended  to  be  used  as  a  scheduled  service.  That 
is,  it  begins  and  ends  operation  at  predetermined  times.  (See  note  1  in  Section  5.6). 


5.3^.1.1.1^  Formal  Description 

1.  The  NFSS  can  only  control  the  client  network’s  transmitter  and  receiver  at  specific  times  (ref¬ 
erenced  to  tg)  that  satisfy 

Ui^iT^p  (EQ8) 

where  /  =  0,1  and  is  given. 

2.  When  activated  at  time  the  NFSS  shall  attempt  to  select  a  common,  “best”  frequency 
from  a  given,  non-empty  sequential  collection  s  {fj} 

3.  At  the  time  ( j  +  T^)  the  NFSS  shall  cease  operation,  leaving  the  client’s  transmitter  and 
receiver  set  to  operate  on  /^. 

4.  The  minimum  period  between  the  start  of  successive  activations  of  the  NFSS.  'Tap-  must  sat¬ 
isfy 

Tj^P^T^.  (EQ9) 


5.3,2.1.1.U  Assumptions 

1.  An  implementation  shall  specify  the  mirumum  allowed  value  for 

2.  An  implementation  shall  specify  the  maximum  number  of  elements  in  the  sequential  collection 

3.  An  implementation  may  provide  additional  means  for  notifying  a  client  of  the  “bestf ’  frequency 

/^.  For  example,  may  be  loaded  into  a  memory  location  that  the  client  can  read. 


1.  A  je<rii«nf^colIecfton  is  defined  as  a  coUectioa  whose  members  can  be  accessed  via  an  indoi. 
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4.  An  implementation  shall  specify  the  minimum,  and  maximum,  values  for  frequen¬ 
cies  in  the  collection  {/,  } 

'-'J‘  sc 

5.3JZ.1.1.2  Monitor,  Controller,  and  Archiver  Capability  (MCA.CAP) 

The  Monitor,  Controller,  and  Archiver  ca{»bility  is  a  composite  of  several  capabilities.  The  NFSE 
System  Archiver  ct^nbility  provides  a  log  of  the  operation  of  the  NFSE  System.  This  log  consists  of  sev¬ 
eral  files  that  first  ate  written  to  the  console’s  disk  and  subsequently  are  transferred  to  a  permanent  stmage 
medium,  such  as  magnetic  tsqx.  The  intent  is  that  this  log  should  be  of  aifiiciem  detail  to  permit  duplica¬ 
tion  of  field-test  results  in  the  laboratory,  as  was  done  for  the  NRL  UNT  tests.  [4]  The  NFSE  System  also 
provides  a  system  monitoring  and  control  capability,  which  is  accessible  to  the  system  operator.  The  inter¬ 
face  to  this  service  shall  provicte  the  operator  with  a  means  of  ascertaining  the  status  of  the  NFSE  System 
and  for  starting  and  stopping  the  system. 

5.3.2.1.1.3  Test-Plan  Description  Capability  (TPD.CAP) 

This  capabiUty  :'hall  provide  the  means  to  specify  the  tests  to  be  performed  with  the  NFSE  System. 

5.3.2.1.2  ModeB 

Mode  B  is  like  Mode  A  with  the  exception  that  the  NFSE  uses  (optionally)  its  own.  internal  net¬ 
work  to  pass  user  traffic.  It  is  intended  that  Mode  B  be  used  for  initial  tests  of  the  NFSE  System  {mor  to 
final  tests  using  Mode  A.  This  mode  can  be  used  without  the  optional  internal  network,  if  one  is  interested 
solely  in  exercising  the  Network  Frequency  Selection  Service. 

5.3J.1  J.1  Network  Frequency  Selection  Service  (NFSS) 

See  Section  S.3.2.1.1.1. 

5.3.2.1.2.2  Monitor,  Controller,  and  Arcblver  Capability  (MCA_CAP) 

See  Section  5.3.2. 1 . 1 .2 

5.3JLU,3  Internal  Network  Capability  (IN^CAP) 

The  internal  network  shall  be  capable  of  simulating  user  traffic  or  passing  real  traffic  that  it 
receives  from  other  networks  via  the  Internet  Protocol  (IP). 

5 JJ.U.4  Test-Plan  Description  CapaUlity  (TPD.CAP) 

See  Section  5.3.2. 1.1.3. 

53,2.13  Mode  C 

533.13.1  Network  Frequency  Selection  Service  (NFSS) 

See  Section  5.3.2.1. 1.1. 
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5.3JLU.2  Monitor,  Controller,  and  Archiver  Capability  (MCA.CAP) 

See  Section  S.3.2.1.1.2 

53J2.13.3  Internal  Network  Capability  (IN_CAP) 

See  Section  S.3.2.1.2.3. 

5^^13.4  Test'Plan  Description  Capability  (TPD.CAP) 

See  Section  S.3.2.1.1.3. 

532,2  Syst^  Capability  Relationships 

Table  12  summarizes  the  relationships  between  the  NFSE  System  capabilities  and  the  modes  of 
the  system.  An  X  indicates  that  a  capability  exists.  In  Modes  B  and  C  the  system  can  operate  with  or  with¬ 
out  the  Internal  Network. 

Table  12:  NFSE  System  capabilities  associated  with  various  system  modes. 


Mode 

Name  of  Capability 

D 

B 

B 

c 

c 

NFSS 

m 

X 

X 

X 

X 

MCA.CAP 

X 

X 

X 

X 

X 

TPD.CAP 

X 

X 

X 

X 

X 

IN_CAP 

X 

X 

5.323  External  Interface  Requirement 

Figure  4  identifies  and  names  the  external  interfaces  for  the  NFSE  System.  There  is  also  an  opera¬ 
tor  interface  for  monitoring  and  controlling  the  NFSE  System;  however,  we  treat  that  as  an  internal  inter¬ 
face.  which  is  described  in  a  later  section. 

53.23.1  GPS  Interface 

The  GPS  interface  shall  consist  of  an  RS232  serial  port  through  which  the  external  system  shall 
provide  precise  Greenwich  Mean  Hme  (GMT)  and  1  ppm  (pulse  per  millisecond)  time  intervals  for  use  by 
the  NFSE  System. 

53333  Modem  Control  Interface  via  NOSC  BLC 
TBD 
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Figure  4  NFSE  Syitem  extenial  interfacci. 

5.3^33  M<fdein  Data  Interface  via  NOSC  BLC 
TBD 

5333.4  'Dransmitter  Control  Interface 

The  transmitler  control  interface  shall  allow  remote  control  of  all  transmitter  functions  controllable 
from  the  front  panel,  including  frequency  selection. 

53333  Receiver  Control  Interface 

TIk  receiver  control  interface  shall  allow  remote  control  of  all  receiver  functions  controllable  from 
the  front  panel,  including  frequency  selection 

5.4  Quality  Assurance  Provisions 

TBD 

5.5  Preparation  for  Delivery 

TBD 

5.6  Notes 

1.  An  asynchronous  mode  of  operation  for  the  NFSS  was  considered  but  rejected  for  the  follow¬ 
ing  reason.  Owing  to  the  unreliability  of  HF  communication  links  in  a  threat  environment, 
there  is  no  way  to  guarantee  that,  in  a  timely  manner,  all  nodes  in  the  networit  could  be  made 
aware  of  an  asynchronous  request  to  perform  the  Netwoilc  Frequency  Selection  Service. 

5.7  Revisions  to  Section  5 


None. 
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6.  SYSTEM  DESIGN 


6.1  Scope 

6.1.1  Identification 

Section  6  provides  the  equivalent  of  the  System/Segment  Design  Document  (SSDD)  for  the  Net¬ 
work  Frequency  Selection  Experiment  (NFSE)  System.  This  design  derives  from  the  system  requirements, 
which  are  given  in  Section  S. 

6,12  System  Overview 
See  Section  S.1.2. 

6.U  Section  Overview 

This  section  describes  the  NFSE  system  design  and  its  operational  and  supprxt  environments.  It 
describes  the  organization  of  the  NFSE  system  as  composed  of  Computer  Software  Coirhguration  Items 
(CSCIs)  and  manual  operations.  There  are  no  Hardware  Configuration  Items  (HWCIs)  included  in  this  sys¬ 
tem. 


6.2  Referenced  Documents 
See  Section  3. 

63  Operational  Concepts 

63.1  Misaon 

6.3.1.1  User  Needs 

The  need  for  a  network  frequency  selection  service  is  documented  in  [1],  which  contains  the  fol¬ 
lowing: 


‘The  present  HF  communication  systems  on  most  Navy  i^atforms  are  manually  operated. 
They  require  letuning  of  receivos,  transmitters,  filters  a^  multicouplers  every  time  the 
frequency  is  changed,  thus  requiring  a  significant  amount  of  labor  to  operate  the  system. 
Th^  changes  are  required  by  dianges  in  operating  locationsfscenarios  and  changes  in 
sky-wave  HF  propagation  at  difEeient  times  of  day.  This  manual  operation  takes  many 
minutes  to  houTS,  requites  a  relatively  high  operator  skill  level,  and  is  a  source  of  errors 
causing  low  system  availability.” 

Subsequently,  reference  [1]  goes  on  to  describe  the  fdlowing  efint  to  address  these  needs: 

‘This  effort  will  incorporate  HF  netwmkii^  techniques,  and  demonstrate  auto¬ 
matic  frequency  selection,  network  establishment,  and  connectivity  maintenance.  This 
task  will  gramine  die  dynamics  of  fiequency  selection,  including:  acquiring  and  distribut- 
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ing  link  performance  data  for  all  links  and  frequencies:  identifying  a  "best”  frequency  or 
frequencies:  distributing  that  information  among  all  itodes;  initiating  operation  on  the 
selected  frequency;  and,  updating  the  entire  process  to  maintain  good  network  operation.” 

6.3.1.2  Primary  Mission 

Hie  primary  mission  of  the  system  is  to  demonstrate  a  technique  for  selecting  an  opiating  fre¬ 
quency  for  a  single-channel  HF  network. 

6.3.2  Operational  Environment 

The  intended  operational  environment  for  the  NFSE  system  is  the  CSS  Testbed,  which  is  described 
in  Section  6.3.3.2.I. 

6.33  Support  Environment 

6.33.1  Support  Concept 

This  subsection  describes  the  support  enviroiunent  for  the  operational  system  during  the  Produc¬ 
tion  and  Deployment  phase  of  the  system  life  cycle. 

NRL  shall  be  responsible  for  hardware  and  software  support  for  two  NFSE  System  nodes  while 
these  nodes  are  in  the  development  phase.  After  the  NFSE  System  nodes  have  been  tested  in-lab  at  NRL 
and  have  operated  properly,  the  NFSE  System  software  shall  be  ported  to  NRaD  hardware  in  preparation 
for  held  tests.  NRL  shall  continue  to  supply  maintenance  suppon  for  the  NFSE  System  software  through¬ 
out  the  field  test  phase.  NCCOSC-NRaD  shall  suf^ly  hardware  support  for  the  field-test  version  of  the 
NFSE  System. 

NRL  shall  purchase  two  VME-based  multi-fnrocessor  systems  to  be  used  for  NFSE  System  nodes. 
This  hardware  shall  be  similar  to  that  used  for  the  UNT  demonstrations.  In  addition,  NRL  shall  supply  one 
Sun  3  workstation  for  use  in  developing  the  NFSE  System  software.  The  latter  shall  be  upgraded  to  a  Sun 
Sparcstation  in  1993. 

Software  support  for  the  operational  system  shall  consist  of  the  items  shown  in  Table  13.  The  sys¬ 
tem  console  shall  tun  the  Unix  operating  system.  Hie  vxWorics  software  has  two  components.  One  of  th^ 
runs  on  the  console  (vxWorks  host)  and  the  other  runs  on  the  target  MVME135  card.  The  latter  incluttes 
the  vxWorks  real-time  operating  system.  The  MVME333  boards  are  sui^lied  with  a  monitor  program, 
which  supports  the  use  of  that  board. 


Table  13:  Support  software  for  ttie  operational  ^tem 


Name 

Description 

vxWorks 

Real-time  software  environment 

Unix 

Operating  system  for  the  system  console 

MVME333Bug 

Monitor  program  for  MVME333  board 
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6.33.1.1  Government  and  Contractor  Support 

NRaD  shall  be  responsible  for  providing  su{^rt  for  the  use  of  the  CSS  testbed.  (Sec  Section 
6.3.3.2.1). 

NRL  may  use  contractors,  as  needed,  to  help  {Hcpare  for  and  carry  out  the  held  tests. 

6.33.2  Support  Facilities 

6.33.2.1  CSS  Testbed  at  NCCOSC-NRaO 

The  Communication  Support  System  (CSS)  Testbed  at  NCCOSC-NRaD  shall  be  the  principal  site 
for  the  NFSE  field  demonstrations  and  tests.  This  testbed  consists  of  five  permanent  sites,  which  are  shown 
in  Figure  S.  NCCOSC*NRaD  shall  supply  the  hardware  required  to  conduct  the  field  tests. 


6.333  Supply  System 

Responsibility  for  supplying  hardware  for  the  NFSE  system  rests  with  NCCOSC-NRaD  or  the 
organization  that  they  delegate. 

6.33.4  Government  Agencies 

NRL  shall  be  responsible  for  developing  and  testing  the  NFSE  System.  NCCOSC-NRad  shall  be 
re^nsible  for  the  external  environment  of  ^  NFSE  System,  as  shown  in  Hgure  1. 
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6.3.4  System  Architecture 

The  top-level  components  of  the  NFSE  system  design  and  its  environment  are  shown  in  Figure  6. 
The  NFSE  system  consists  of  the  following  CSCIs;  Network  Controller  (NC),  Link  Connoller  (LC).  and 
System  Controller  (SC).  The  operator  interacts  directly  with  the  System  Controller  (SC)  and  indirectly, 
through  the  SC,  with  the  Network  Controller  (NC)  and  Link  Controller  (LC).  The  Network  Controller  and 
Link  Controller  also  interface  to  each  other. 


Figure  6  System  architecture  showing  CSCI’s  and  external  interfaces. 


6.4  System  Design 

Figure  3  shows  an  example  top-level  timing  diagram  for  the  NFSE  System.  Figure  7  [nx)vides  the 
next  level  of  detail  for  the  system  timii^  structure. 

Time  is  divided  into  periods  in  which  the  NFSS  is  active  and  periods  when  the  NFSS  is  inactive. 
During  an  active  cycle,  time  is  divided  into  M  periods  of  operation  at  different  test  frequencies.  These  fre¬ 
quencies  are  selected  from  the  sequential  collection  {fj}  and  stored  in  the  array  fa[] .  Details  of  this 
selection  process  are  given  in  Section  10.1.4.10.1.2.1. 

For  operation  at  each  frequency  test  cycle,  ex(%pt  the  last  one,  time  is  divided  into  Np  frames.  The 
last  frequency  test  cycle  is  twice  as  long  and  contains  2Np  frames.  Each  frame  is  further  divided  into  N 
time  slots.  During  the  period  of  operation  at  a  given  test  frequency,  the  network  goes  through  die  following 
phases:  1)  probity  to  ^termine  connectivities,  2)  i^twork  structuring  to  sui^xxt  the  routing  of  traffic,  3) 
dissemination  of  connectivity  information  by  relaying,  and  finally,  4)  evaluation  of  the  suitability  of  the 
test  frequency. 
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frame  Np,  each  node  evaluates  the  test  frequency  based  on  a  metric  that  is  described  in  Section 
10.1.4.10.1.2.4. 

At  the  end  of  the  testing  period  for  the  first  frequency,  the  network  begins  the  process  of  “flooding" 
to  all  nodes  information  about  the  “best"  frequency  and  the  value  of  the  metric  for  that  frequency  The 
value  of  the  flooded  metric  can  be  thought  of  as  a  measure  of  the  strength  of  the  “wave"  for  that  particular 
flood  of  messages.  As  better  frequencies  are  found,  a  luw,  stronger  wave  of  “flooding”  occurs  which  enin- 
guishes  any  previous  waves  that  it  encounters.  In  order  that  there  is  sufficient  time  to  complete  the  flooding 
process  for  the  case  where  the  best  frequency  is  also  the  last  one  tested,  the  design  allows  for  twice  the 
number  of  transmission  frames  for  the  last  test  frequency. 

6.4.1  HWCI  Identification 

No  HWCIs  are  included  in  this  system. 

6.4.2  CSCI  Identification 

The  NFSE  Sys  tem  is  composed  of  three  CSCIs,  which  are  called  the  Network  Controller,  the  Link 
Controller,  and  the  System  Controller. 

6.4.2.1  Network  Controller  (NC^  CSCI 

6.4.2.1.1  Purpose 

The  NC  implements  those  functions  of  the  NFSE  System  that  would  normally  be  allocated  to  the 
Network  Layer  in  an  ISO  system  architecture.  It  implements  the  network  frequency  selection  service  and 
the  network  communication  service  requirements  given  in  Section  S.3.2.1.  The  NC  design  should  place 
emphasis  on  the  reuse  of  hardware  and  software  from  NRL’s  UNT  project 

6.4.2.U  System  Capabilities  Addressed  by  the  Network  Controller 

The  Network  Controller  implements  the  Network  Frequency  Selection  Service  (NFSS)  and  Inter¬ 
nal  Network  C^ability  (IN_CAP)  requirements  of  the  NFSE  System.  The  Network  Controller  also  sup¬ 
ports  the  monitoring  capability  includ^  in  the  Monitor,  Controller,  and  Archiver  Capability  (MCA_CAP) 
of  the  NFSE  System  by  providing  network  status  information  to  the  System  Controller. 

6A2.13  External  System  Interfaces  Implemented  by  the  NC 
The  NC  does  not  have  any  external  NFSE  System  interfaces. 

6.4.2.2  Link  Controller  (LC)  CSCI 

6.4.2.2.1  Purpose 

The  LC  implements  those  functions  of  the  NFSE  System  that  would  normally  be  allocated  to  the 
Link  Layer  in  an  ISO  system  architecture. 
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6.4  System  Capabilities  Addressed  by  the  Link  Controller 

The  LC  implements  the  link  level  services  required  by  the  Network  Controller  in  order  for  the  lat¬ 
ter  to  do  its  job. 


6.4.2.23  External  System  Interfaces  Implemented  by  the  LC 

6.43.23.1  GPS  Interface  (IF_LC_GPS) 

The  GPS  physical  interface  is  an  RS232  pon,  which  is  configured  as  shown  in  Figure  8. 
DB25  Male 


data  from  GPS  receiver 
signal  ground 
1  ppms 


Notes: 

1.  The  GPS  port  shall  be  configured  as  a  DTE. 

2.  Port  parameters:  9600  bps,  8  data  bits.  1  stop  bit,  no  parity,  asynchronous. 

3.  RS232  voltage  levels  on  pin  3. 

4. 0  to  10  volts  on  pin  8  (into  SO  ohm  load). 

5.  Time  output  on  pin  3  to  begin  within  0.1  millisecond  of  the  UTC  1  sec  rollover. 

Figure  8  GPS  interface. 


The  serial  format  for  inputting  timing  information  is  shown  in  Table  14.  TMs  format  corresponds 
to  that  of  the  GPS  receiver  used  in  the  UNT  tests.[14]  Bit  0  of  byte  1  is  the  first  to  be  transmitted. 

Table  14:  GPS  serial  tiiiie«of-day  input  format 


Byte# 

BitO 

Bitl 

Bit  2 

Bit  3 

Bit  4 

Bit  5 

Bit  6 

Bit? 

1 

si 

s2 

s4 

s8 

slO 

s20 

s40 

0 

2 

ml 

m2 

m4 

m8 

mlO 

m20 

m40 

3 

hi 

h2 

h4 

h8 

hlO 

h20 

0 

0 

4 

dl 

d2 

d4 

d8 

dlO 

d20 

d40 

d80 

5 

dlOO 

d200 

0 

0 

0 

0 

0 

0 

6.43.23.2  Modem  Interface  via  NOSC  BLC  (IF_LC_NOSC) 

TBD 

6.43.233  Transmitter  Control  Interface  (IF_LC_XCTL) 

Initial  plans  are  based  on  the  use  of  the  Harris  RT-1446  transceivers,  which  were  used  in  the  UNT 
demonstrations.  The  UNT  version  of  this  transceiver  does  not  have  remote  control  capsd)ility.  However,  a 
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remote  control  interface  board  (Harris  RF-362)  can  be  fHirchased  for  the  UNT  transceivers  for  $295  each. 
If  this  transmitter  configuration  is  used.  Harris  will  supply  the  specifications  for  the  transmitter  control 
interface. 

6.42.23.4  Receiver  Control  Interface  (IF_LC_RCTL) 

The  receiver  remote  control  interface  is  described  in  [15]. 

6.4JL2.4  Dedgn  Constraints 

The  LC  (tesign  should  place  emphasis  on  the  reuse  of  hardware  and  software  from  NRL’s  UNT 

project 

6.4^.3  System  Controller  (SC)  CSCI 
6.4J.3.1  Purpose 

The  primary  purpose  of  the  SC  is  to  provide  a  user  interfrK:e  into  the  NFSE  system.  The  SC  imple¬ 
ments  the  requirements  fw  monitoring,  controlling,  and  data  archiving  for  the  NFSE  system  as  specified  in 
Section  5.3.2. 1.  The  SC  design  should  place  en^rfiasis  on  the  reuse  of  hardware  and  software  from  NRL’s 
UNT  project. 

6.4232  System  Capabilities  Addressed  by  the  System  Controller 

The  System  Controller  implements  the  Monitor,  Controller,  and  Archiver  Capability  (MCA_CAP) 
and  the  Test-Plan  Description  Ctq^ility  (TPD.CAP)  of  the  NFSE  System. 

6.4233  External  Interfaces 

Although  the  SC  does  have  an  operator  interface,  we  treat  this  as  an  internal  interface,  which  is 
described  in  Section  11.3.7. 

6.4  J  Manual  Operations  Identification 

The  Manual  Operations  for  the  NFSE  System  are  grouped  into  the  following  four  categories:  test 
description,  system  startup,  system  monitoring  maintenance,  and  system  shutdown.  These  operations 
are  (kscribed  below. 

6.4J.1  Describe  Test  (SET.TEST) 

TBD 

6.432  Start  System  (SYS.START) 

TBD 
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6.4 J.3  Monitor  and  Maintain  System  (SYS.RUN) 


TBD 

6.43.4  Shutdown  System  (SYS.STOP) 
TBD 

6.4.4  Internal  Interfaces 


The  top-level,  internal  interfaces  of  the  NFSE  system  are  shown  in  Figure  9.  In  addition  to  the  real 
interfaces,  we  also  show  the  virtual  (peer-to-peer)  interfaces.  The  latter  interims  connect  peer  layers  on 
separate  nodes. 


6.4.4.1  HWCI-toHWCl  Interfaces 
None. 

6.4 A2  HWCI-to-CSCI  Interfaces 
None. 

6.4.43  CSCI-to-CSCI  Interfaces 

All  of  the  iniemai  interfaces  shown  in  Figure  9  represent  CSCI-to-CSCI  interfaces.  A  brief 
descripdon  of  each  of  these  interfaces  fDllows. 
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6.4.4.3.1  IF_OP_SC 


IF_OP_SC  is  the  interface  between  the  NFSE  System  Operator  and  the  System  Controller  CSCI. 
Physically,  this  interface  is  the  keyboard,  screen,  and  mouse  that  belong  to  the  System  console.  The  soft¬ 
ware  interface  is  accessed  through  the  Unix  operating  system  of  the  System  console.  The  requirements  for 
this  interface  are  given  in  section  9.3.3. 

6.4.4.3J  IF_SC_NC 

The  workstation,  which  serves  as  the  System  console,  interfaces  to  the  Network  Controller  through 
the  interface  IF_SC_NC.  Physically,  this  interface  is  an  ethemet  connection.  The  requirements  for  this 
interface  are  given  in  section  9.3.S. 

6.4.4.33  IFjSC.LC 

The  System  console  also  provides  an  interface  for  direct  connection  to  the  Link  Controller  through 
the  1F_SC_LC.  Physically,  this  interface  is  an  RS232  connection.  The  requirements  for  this  interface  are 
given  in  section  9.3.4. 

6.4.4.3.4  IF_NC_LC 

The  interface  between  the  Network  Controller  and  the  Link  Controller  at  a  node  is  called  the  IF_N- 
C_LC  interface.  Physically,  this  interface  is  made  up  of  the  VME  backplane  and  the  MVME224-1  shared 
memory  board  within  the  BLC  chassis  (see  figure  1).  The  requirements  for  this  interface  are  given  in  sec¬ 
tion  9.3.2. 

6.4.4.3.5  IF_NC_NC 

There  are  two  peer  level  interfaces  in  the  NKE  System.  These  interfaces  deal  with  communica¬ 
tion  between  CSCIs  on  different  nodes.  The  peer  level  interface  between  network  controllers  on  different 
nodes  is  called  the  IF_NC_NC  interface.  The  requirements  for  this  interface  are  given  in  section  9.3.6. 

6.4.4.3.6  IF_LC_LC 

The  other  peer  level  interface  in  the  NFSE  System  is  between  link  controllers  on  different  nodes. 
This  is  called  the  1F_LC_LC  interface.  Its  requirements  are  given  in  section  9.3.7 

6.5  Processing  Resources 

The  processing  resources  for  the  NFSE  System  are  those  shown  in  figure  1.  These  resources  are 
described  below. 

6.5.1  System  Console  (CONSOLE) 

The  console  is  a  Sun  Sparcstation  with  associated  hard  disk  and  tape  drive.  At  least  SO  megabytes 
of  storage  must  be  available  for  use  by  the  NFSE  System.  The  drive  is  needed  to  archive  the  test 
results. 
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6.5JI  Non>Real*tiiiie  Network  Controiier  Processor  (NC_NRT) 


The  Non- Real-time  NC  Processor  (Proc  #0)  must  be  an  MVME135,  MVME135A.  or  suitable  sub¬ 
stitute. 

6.53  Real>time  Network  Controller  Processor  (NC.RT) 

The  Real-time  NC  Processor  (Proc  #1)  must  be  an  MVME135,  MVME135A,  or  suitable  substi¬ 
tute. 

6.5.4  Shared  Memory  (M224NRL) 

At  least  4  megabytes  of  shared  memory  must  be  available  to  the  NFSE  System’s  VME-based  hard¬ 
ware.  A  Motorola  MVME224-1  or  suitable  substitute  is  required. 

6.53  Ethernet  Controller  (LANCNTR) 

A  VxWorks-compatible  etheinet  controiier  is  needed  to  connect  the  NFSE  System’s  VME  chassis 
to  the  System’s  console. 

6.5.6  Link  Controller  Processor  (M333NRL) 

A  Motorola  MVME333  or  suitable  substitute  is  required  by  the  NFSE  System’s  Link  Controller 
software. 

6.6  Quality  Factor  Compliance 

TBD 

6.7  Requirements 'Traceability 

Table  15  summarizes  the  system  capabilities  addressed  by  each  of  the  HWCIs,  CSCIs,  and  Manual 
Operations  of  the  NFSE  System. 

Table  15:  Requirements  IVaceability  Matrix 
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Table  15:  Requirements  Traceability  Matrix 


NFSS 

MCA.CAP 

IN.CAP 

TPD.CAP 

SYS.RUN 

X 

X 

X 

6.8  Notes 

None. 

6.9  Revisions  to  Section  6 

None. 
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7.  SOFTWARE  DEVELOPMENT  PLAN 


Section  7  provides  the  equivalent  of  a  2 167 A  Software  Development  Plan  (SDP)  for  the  NFSE 

System. 

7.1  Scope 

7.1.1  Identification 

This  SDP  is  for  the  NFSE  System  and  is  applicable  to  all  CSCIs  identified  in  Section  6.4.2. 

7.U  System  Overview 

See  section  S.1.2  on  page  13. 

7.13  Section  Overview 

This  section  describes  NRL’s  plans  for  conducting  software  development  for  the  NFSE  System. 

7.2  Referenced  Documents 

See  Section  3. 

7.3  Software  Development  Management 

7.3.1  Project  Organization  and  Resources 

7.3.1.1  NRL  Facilities  to  be  used 

NRL  faciUties  to  be  used  include  office  spaces,  computer  resources,  and  the  Distributed  Simula 
tion  and  Prototyping  Testbed  (DSPT).  These  facilities  are  presently  located  at  NRL  in  Building  26. 

7.3.1.2  Government  Furnished  Equipment,  Software,  and  Services 

The  hardware,  shown  in  Table  16,  and  the  software,  shown  in  Ihble  17,  shall  be  obtained  with 
project  funds. 


Thble  16:  Hardware  Items  to  be  Obtained 


Item 

Description 

Qty. 

Ordered 

Received 

MVME94SB-1 

VME  Benchtop  Enclosures 

2 

Yes 

Yes 

MVME135A 

CPU  (4  Mbyte  DRAM) 

5 

Yes 

Yes 

MVME224A-1 

Memory  (4  Mbyte  DRAM) 

2 

Yes 

Yes 

MVME333-2 

Serial  I/O  Module 

2 

Yes 

Yes 
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Table  16:  Hardware  Items  to  be  Obtained 


Item 

Description 

Qty. 

Ordered 

Received 

MVME705A 

Transition  Board  for  333 

2 

Yes 

Yes 

ENP-IOL 

Ethernet  Controllers 

2 

Yes 

Yes 

Harris  RF-362 

Remote  Controller  board 

m 

No 

No 

Table  17:  Software  Items  to  be  Obtained 


Item 

Description 

Qty. 

Ordered 

Received 

vxWorks 

Real-time  software  environ¬ 
ment 

1 

Yes 

Yes 

7.3.1.3  Organization  Structure 

Code  5521  personnel  at  NRL  shall  be  responsible  for  the  development  of  the  NFSE  System.  This 
code’s  position  in  the  NRL  organizational  structure  appears  in  Figure  10. 


Figure  10  Code  SSZl’i  potitioa  in  NRL  otganizationel  itnicture. 
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7.3.1.4  Personnel 

The  manager  for  the  NFSE  System  Development  Project,  hereafter  to  be  referred  to  as  the  Project, 
is  Mr.  Dennis  N.  McGregor.  Section  Head  for  NRL  Code  5521.  The  Technical  Leader  for  the  Project  is  Dr. 
Dennis  J.  Baker,  a  member  of  this  Section. 

7.3  J  Schedule  and  Milestones 


Table  18  shows  the  schedule  for  performing  ftte  tasks  associated  with  NFSE  projea.  Also  dis¬ 
played  are  the  milestones,  which  specify  when  the  deliverables  shown  in  table  19  are  due. 

Table  18:  Schedules  and  milestones 


Tasks 

1 

1992 

1993 

1994 

4 

1 

2 

3 

4 

1 

2 

3 

4 

1 

2 

3 

4 

1.  Design  of  Network  Frequency  Selection  Service 
(NFSS) 

■ 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

■ 

2.  Identify  new  hardware/software  needed 

L' 

3.  Design  field  test  driver  and  archiver 

■ 

C 

■ 

4.  Write  software  requirements  document 

1 

Z1 

5.  Write  software  design  guide 

■ 

c 

■■ 

2 

6.  Code  NFSS  and  suppoit  software 

■ 

■ 

i 

■■ 

■■ 

< 

k 

7.  Simulation  testing  of  NFSS 

■ 

■ 

■ 

■ 

■ 

""" 

1 

■ 

■ 

■ 

■ 

8.  Develop  plans  for  field  tests 

r 

1 

■ 

■ 

■ 

1 

9.  Integrate  NFSS  &  test-support  software  into  target  HW/ 
SW  environment 

■ 

■  I 

1 

1 

1 

1  ■ 

■ 

■ 

E 

] 

1 

1 

10.  Perform  in-lab  tests  of  field-test  system 

■ 

■ 

■ 

■ 

■ 

1 

■ 

■ 

■ 

11.  Perform  field  tests 

■ 

■ 

1 

■ 

■ 

■ 

i 

i 

■ 

■ 

C 

■ 

■ 

12.  Analyze  field  test  results 

2 

13.  Project  management 

■ 

■■ 

■ 

■■ 

■■ 

M 

Table  19:  Deliverables 
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7.3Jt.l  Activities 


The  set  of  tasks  necessary  to  complete  the  NFSE  project  are  listed  below. 

Task  1  •  Design  of  Frequency  Selection  Service  (NFSS)  -  This  task  is  to  develop  an  iraplementable 
algorithm  by  which  N  nodes  can  select  the  best  operating  frequency  from  a  given  set  of  allocated 
HF  frequencies.  The  algorithm  must  be  robust  with  respect  to  communication  connectivity 
changes,  irrespective  of  the  causes  of  these  changes.  The  task  must  address  the  following:  (1)  the 
measurements  that  must  be  made  to  evaluate  link  qualities  at  a  given  frequency,  (2)  the  protocol 
for  disseminating  this  link  quality  information  throughout  the  network,  (3)  the  development  of  a 
metric  for  selecting  the  best  frequency  on  a  network-wide  basis,  and  (4)  and  a  protocol  for  install¬ 
ing  the  chosen  frequency  throughout  the  network.  Both  centralized  and  distributed  techniques  for 
implementing  the  NFSS  shall  be  considered.  The  output  of  this  task  shall  be  a  software  specifica¬ 
tion  of  the  NFSS. 

Task  2  -  Identify  new  hardware/software  needed  -  The  objective  of  this  task  is  to  identify  any  spe¬ 
cial  hardware  and  software  needed  to  implement  the  NFSS.  For  example,  it  is  almost  certain  that 
the  NFSS  will  require  computer  control  of  both  the  transmitter  and  receiver.  The  resource  require¬ 
ments  specification  will  also  give  estimates  of  the  cpu  and  memory  requirements  of  the  NFSS,  as 
well  as  specifying  any  timing  constraints  that  must  be  met  This  task  will  also  identify  any  special 
hardware/software  development  tools  that  are  needed  to  fully  implement  the  NFSE  System. 

Task  3  •  Design  Field  Test  Driver  and  Archiver  -  Additional  software  is  needed  for  the  following: 
1)  to  provide  traffic  loads  on  the  network  during  the  field  demonstrations,  2)  to  monitor  the  opera¬ 
tion  of  the  NFSS  during  the  field  tests,  and  3)  to  archive  the  results  of  its  operation  for  more 
detailed  post-analysis  of  its  performance.  The  basic  design  for  accomplishing  these  functions 
shall  be  the  focus  of  this  task. 

Task  4  -  Write  Software  Requirements  Document  -  The  purpose  of  this  task  is  to  generate  specifi¬ 
cations  for  the  NFSS  software  and  any  supporting  software.  The  latter  may  include  test  drivers, 
data  archiver,  and  test  monitor  display  software. 

Task  5  •  Write  software  design  guide  -  The  purpose  of  this  task  is  to  provide  a  software  design  doc¬ 
ument,  which  will  serve  as  the  basis  for  software  coding. 

Task  6  -  Code  the  NFSS  and  test-support  software  -  The  purpose  of  this  task  is  to  use  the  docu¬ 
mentation  and  specifications  of  Taslra  4  and  5  as  the  guide  for  developing  the  requisite  NFSE  Sys¬ 
tem  software  for  the  target  hardware.  The  initial  effort  on  this  task  shall  focus  on  construction  of 
the  software  development  environment  that  shall  be  used  during  the  subsequent  code  develop¬ 
ment 

Task  7  -  Simulation  Testing  of  the  NFSS  -  This  task  is  to  perform  a  simulation  of  the  NFSS  design 
and  run  appropriate  tests  so  as  to  verify  that  the  design  is  not  flawed. 

Task  8  •  Develop  Plans  for  Field  Tests  -  The  purpose  of  this  task  is  to  generate  a  document 
describing  the  M^SE  System  as  it  will  be  performed  in  the  field.  This  document  will  describe  the 
test  objectives,  test  procedures,  data  collection  requirements,  and  data  analysis  procedures.  If  any 
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special  monitoring  tools  are  needed  to  show  the  operation  of  the  NFSS  during  the  actual  held 
demonstrations,  these  tools  shall  also  be  described  in  the  test  plans. 

Task  9  -  Integrate  NFSS  &  Test-Support  Software  into  Target  Hardware/Software  Environment  - 
This  task  provides  for  the  integration  of  the  NFSS  and  support  software  into  the  field  testbed  hard¬ 
ware/software  environment  The  task  is  broken  into  three  phases,  as  indicated  in  the  schedule  of 
Table  18.  During  the  first  phase,  the  goal  is  to  reconstruct  an  HF  networit  node  as  it  existed  in 
NRL’s  UNT  demonstration.  The  NFSE  System  node  shall  be  obtained  by  enhancing  the  capabili¬ 
ties  of  the  UNT  node.  During  the  second  phase  of  diis  task,  the  software  for  the  new  Network  Fre¬ 
quency  Selection  Service  and  related  services  shall  be  integrated  into  the  target  hardware.  During 
the  third  phase  of  this  task,  the  NFSE  System  node  shall  be  integrated  with  the  NOSC  BLC. 

Task  10  -  Perform  in-lab  Tests  of  Field-Test  System  -  The  objective  of  this  task  is  to  perform  back- 
to-back  testing  in  the  laboratory  of  at  least  two,  fully  configured  nodes. 

Task  11  -  Perform  Field  Tests  -  The  actual  demonstration  or  field  tests  would  be  accomplished 
over  a  period  of  about  one  month,  starting  with  only  two  or  three  nodes  and  culminating  with  tests 
using  five  or  more  nodes. 

Task  12  -  Analyze  Field-Test  Results  -  The  purpose  of  this  task  is  to  analyze  the  data  from  the  field 
tests  and  describe  the  results  in  a  final  report 

Task  13  -  Project  Management  -  This  task  covers  manpower  resource  scheduling,  coordination 
with  sponsor,  managing  project  finances,  providing  briefings,  obtaining  contractual  support  as 
required,  and  other  necessary  project  management  functions. 

7.3.2.2  Activity  Network 
Not  available. 

7.3.2.3  Source  Identification 

This  subsection  identifies  and  describes  the  sources  of  the  required  resources  (software,  firmware, 
and  hardware)  for  the  software  development  effort  for  the  NFSE  System.  We  outline  a  plan  for  obtaining 
the  required  resources  and  indicate  the  need  date.  If  the  availability  of  a  particular  item  is  known,  we  also 
give  that  information. 

The  resources  that  are  needed  can  be  grouped  into  those  needed  for  each  of  the  following  three 
phases:  1)  NFSS  development,  2)  hardware/software  integration  performed  at  NRL,  and  3)  final  hardware/ 
software  integration  for  field-test  systent  The  resources  needed  for  Phase  1  are  listed  in  tables  20  and  21. 
Those  required  in  Phase  2  are  given  in  tables  22  and  23.  And  those  that  are  needed  in  Phase  3  are  given  in 
tables  24  and  25. 
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Table  20:  Hardware  Resources  needed  for  NFSS  Development 


Item 

— 

Description 

Source 

Qty. 

Date  Needed 

Availability 

MVME945B.1 

Chassis 

Motorola 

2 

Stan  of  Task  9 

Received 

MVME135A 

CPU 

Motorola 

5 

Stan  of  Task  9 

Received 

MVME224A.1 

Memory 

Motorola 

2 

Stan  of  Task  9 

Received 

MVME333-2 

Serial  I/O 

Motorola 

2 

Stan  of  Task  9 

Received 

MVME705A 

Transition  Board 

Motorola 

2 

Stan  oflhsk9 

Received 

ENP-IOL  • 

Ethernet  Board 

Rockwell 

2 

Stan  of  Task  9 

Received 

Sun  3 

Workstation 

NRL 

1 

Stan  of  Project 

Available 

Sun  Sparcstation 

Workstation 

NRL 

1 

TBD* 

Ordered 

a.  The  Sun  Spaicstation  will  be  needed  when  we  receive  the  version  of  vx Works  that  supports  C++.  This  is 
expected  to  occur  around  April  of  1993. 


Table  21:  Software  Resources  needed  for  NFSS  Development 


Item 

Description 

Source 

Qty. 

Date  Needed 

Availability 

vx  Works 

Real-time  soft¬ 
ware 

Wind  River 

1 

StanofIhsk9 

Received 

vx Works  (for  C++) 

Real-time  soft¬ 
ware 

Wind  River 

1 

ASAP 

March  1993 

Table  22:  Hardware  Resources  needed  for  Field>Test  Node  Development  at  NRL 


Item 

Description 

Source 

Qty. 

Date  Needed 

Availability 

TBD 

TBD 

TBD 

TBD 

1  year  prior  to 

Stan  of  held  tests 

TBD 

Table  23:  Software  Resources  needed  for  Field-Test  Node  Development  at  NRL 


Item 

Description 

Source 

Qty. 

Date  Needed 

Availability 

TBD 

TBD 

TBD 

TBD 

1  year  prior  to 

Stan  of  field  tests 

TBD 
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Table  24:  Hardware  Resources  needed  for  final  integration  with  Field-Test  System 


Item 

Description 

Source 

Qty. 

Date  Needed 

Availability 

TBD 

TBD 

TBD 

TBD 

1  year  prior  to 
start  of  field  tests 

TBD 

Table  25:  Software  Resources  needed  for  final  integration  with  Field-Test  System 


Item 

Description 

Source 

Qty. 

Date  Needed 

Availability 

TBD 

TBD 

TBD 

TBD 

Need  access  to 
HW/SW  6  mo. 
prior  to  start  of 
field  tests 

TBD  (need 
access  to 
HW/SW) 

7.3J3  Risk  Management 

For  the  most  part,  there  is  very  low  risk  during  the  first  two  years  of  the  project  to  develop  and  test 
the  Network  Frequency  Selection  Service.  Most  of  the  high  risk  areas  occur  in  the  third  year.  Table  26  lists 
the  major  risk  areas.  Each  risk  area  is  ranked  as  low,  medium,  or  high  risk  with  regards  to  technical,  cost 
schedule,  and  network  (risk  caused  when  problems  with  one  task  have  an  adverse  impact  on  a  large  num¬ 
ber  of  other  tasks)  factors.  The  following  paragrs^hs  elaborate  on  these  risk  areas. 


Table  26:  Assessment  of  Risk  Areas 


Risk  Area 

Technical 

Risk 

Cost  Risk 

Schedule 

Risk 

Network 

Risk 

Overall  Risk 

Software  Development 
Language 

Medium 

Low 

Low 

Medium 

Medium 

Multi-Contractor, 

Multi-Site 

High 

High 

High 

High 

High 

Field-Test  Resources 
Availability 

n.a. 

High 

High 

High 

High 

7.3  J.l  Software  Language  Development 

The  high-level  language  C++  has  been  selected  for  most  of  the  software  for  the  NFSE  System. 
This  was  the  language  used  to  implement  the  Network  Controller  for  the  UNT/NRL  tests.  It  is  a  risk  area 
because  C++  is  not  directly  supported  by  the  vxWorks  real-time  software.  Nevertheless,  it  is  felt  that  this  is 
not  a  high  risk  area  because,  if  needs  be,  C  code  can  be  obtained  from  the  C++  code,  and  vx Works  does 
suppOTt  C.  TVvo  additional  steps  taken  to  reduce  the  risks  associated  with  using  C++  were  the  following:  1) 
ffniist  the  services  of  a  contractor  (Jade  Simulations  International)  tfiat  is  familiar  with  porting  C++  to 
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VME  systems,  and  2)  obtain  C++  support  from  vx  Works  as  soon  as  it  becomes  available.  In  regards  the 
laner,  we  are  seeking  to  have  NRL  serve  as  a  beta  test  site  for  the  soon-to-be-tested  C-m-  suppon  for 
vx  Works. 

7.33.2  Multi'Contractor  and  Multi-Site 

During  the  third  year  of  this  project,  there  is  a  large  amount  of  closely  coordinated  work  that  must 
be  done  by  NRL  and  NCCOSC-NRaD  workers.  Hiis  arises  because  of  the  need  to  integrate  the  NFSE  Sys¬ 
tem  hardware  and  software  into  a  single  VME  chassis  that  is  shared  with  NCCOSC-NRaD  hardware  and 
software.  There  are  many  potential  problems  that  can  arise  as  a  result  of  such  an  integration.  Some  of  these 
problems  could  be  quite  difficult  to  diagnose  and  correct  unless  extremely  close  cooperation  is  achieved 
between  the  two  groups  of  wtu-kers.  Adding  to  the  difficulty  of  achieving  the  requited  level  of  coordination 
between  the  two  groups  is  the  large  geographical  separation  of  the  two  laboratories.  Costs  are  another  con¬ 
sideration  in  bringing  the  two  groups  together  for  tte  required  length  of  time.  An  alternative  to  transport¬ 
ing  one  of  the  groups  to  the  others  facility  for  an  extended  length  of  time  is  to  make  available  to  both 
groups  a  fully-configured  and  operating  node,  which  contains  both  the  NRL  and  NRaD  hardware  and  soft¬ 
ware.  Then  both  groups  could  perform  tests  with  a  fully  integrated  system,  and  integration  bugs  could  be 
worked  out  with  i^one  calls  among  the  NRL  and  NRaD  researchers. 

7.33.3  Field-Test  Resources  Availability 

A  critical  item  for  the  successful  execution  of  the  third  year  field-test  of  the  NFSS,  is  the  availabil¬ 
ity  of  the  hardware  needed  by  NRL  researchers  to  construct  a  com^dete  and  functioning  node.  This 
includes  all  of  the  hardware  and  software  that  would  exist  at  a  node  in  the  held  test  Such  hardware 
includes:  transmitters,  receivers,  modems,  GPS  receivers,  multicouplers,  antennas,  etc.  The  second  critical 
need  is  for  NRL  researchers  to  have  adequate  access  to  all  field  test  facilities  for  preliminary  testing  and 
debugging. 


7.33.4  Minimizing  the  Risks  Associated  witfi  Field  Tests 

As  noted,  all  of  the  high  risk  areas  are  associated  with  field-tests  that  require  the  integration  of 
NRaD  and  NRL  hardware  and  software  into  a  single  system.  Such  an  integration  effort  is  not  necessary  to 
prove  the  concepts  of  a  Network  Frequency  Selection  Service.  In  an  effon  to  avoid  these  integration  costs, 
the  NFSE  System  is  being  designed  to  work  with  or  without  a  co-resident  HAMA  netwOTk. 

7.3.4  Security 

No  security  features  shall  be  included  in  this  initial  demonstration  of  a  Network  Frequency  Selec¬ 
tion  Service. 

7.33  Interface  with  Associated  Contractors 

Jade  Simulations  International  (JSI)  shall  provide  assistance  with  code  development  and  simula¬ 
tion  of  the  NFSE  System.  The  point  of  contact  for  JSI  is  Dr.  Greg  Lomow.  Dr.  Dennis  Baker  of  NRL  shall 
provide  technical  direction  for  the  JSI  effort  Mr.  Dennis  McGregtH*  of  NRL  Code  5521  shall  serve  as  the 
Contracting  Officer’s  Tbchnical  Representative  (COTR)  on  the  JSI  contract 
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7.3.6  Interface  with  Software  IV&V  Agents 


Not  applicable. 

7.3.7  Subcontractor  Management 

Dr.  Dennis  Baker  of  NRL  Code  SS21  shall  work  directly  with  JSI  contracting  personnel  on  a  day 
to  day  basis  and  provide  the  necessary  technical  guidance  to  the  subcontractor. 

7.3.8  Formal  Reviews 

NRL  shall  present  progress  on  the  development  and  testing  of  the  Network  Frequency  Selection 
Service  at  the  annual  Office  of  Naval  Technology’s  (ONT)  6.2  Block  Reviews. 

73.9  Software  Development  Library 

The  software  de  /elopment  library  (SDL)  consists  of  all  documents,  source  code,  cominled  code, 
change  requests,  etc.  associated  with  the  system.  It  also  consists  of  all  commercial  off-the-shelf  (COTS) 
and  non-developmental  software  used  for  conducting  and  supporting  the  project 

Formal  tracking  and  change  control  shall  be  imposed  on  this  document  and  on  all  source  code  that 
makes  up  the  NFSE  System.  The  Unix-based  Revision  Control  System  (RCS)  shall  be  used  to  implement 
version  control  for  all  source  code. 

7.3.10  Corrective  Actions  Process 

Corrective  actions  shall  be  reported  to  Dr.  Dennis  Baker  of  NRL  Code  5521  for  authorization  to 
make  changes. 

7.3.11  Problem/Change  Report 

No  special  format  is  required  to  report  problem.  However,  a  request  for  change  should  include  the 
following:  a  description  of  the  proposed  change,  justification  for  the  proposed  change,  identification  of  the 
person  suggesting  the  change,  and  date  the  change  request  was  fmpared. 

7.4  Software  Engineering 

7.4.1  Organization  and  Resources  -  Software  Engineering 

7.4.1.1  Organizational  Structure  •  Software  Engineering 

NRL  Code  5521  is  responsible  for  performing  all  software  engineering  for  the  NFSE  System.  JSI 
shall  fvovide  subcontractor  support  for  this  effort  as  needed. 
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7.4. 1.2  Personnel  •  Software  Engineering 

Dr.  Dennis  Baker  shall  be  in  charge  of  software  engineering  for  the  NFSE  System  development. 
He  shall  be  assisted  in  this  task,  as  needed,  by  JSI  perscnnel. 

7.4.1.3  Software  Engineering  Environment 

This  subparagr^  identifies  and  describes  the  plans  for  establishing  and  maintaining  the  resources 
(software,  firmware,  and  hardware)  necessary  to  performing  the  software  engineering  activities. 

7.4.1.3.1  Software  Items 

TIm  following  software  shall  be  available  for  supporting  the  NFSE  System  during  development. 
NRL  shall  im)cuie  vxWorks  real-time  software  suf^rt  for  this  project  In  addition,  NRL  shall  make  the 
following,  in-house  software,  available  for  suppon  of  the  NFSE  System;  C-h-  compiler/translator  (Gnu 
C++  compiler  and/or  C-ftont  translator),  C++  software  development  enviroiunent  (Object  Center),  com¬ 
mercial  simulation  software  (Sim++),  word  processor  (FrameMaker),  editor  (Gnu  Emacs),  software  ver¬ 
sion  control  (Revision  Control  System  (RCS)),  system  design  support  (Thrbo-Case). 

NRL  shall  also  make  available  for  this  project  the  Distributed  Simulation  and  Prototyping  Testbed 
(DSPT).  The  DSPT  provides  an  environment  for  conducting  both  real-time  and  non-real-time  tests  of  com¬ 
munication  systems  software.  It  does  this  by  emulating  the  software  environment  in  which  the  communica¬ 
tion  software  is  to  be  immersed.  The  DSPT  provides  software  interfaces  to  RF  transmission  hardware, 
which  emulate  the  target  system  interfaces  and  which  interact  via  simulated  communication  channels.  It 
includes  models  for  both  HF  groundwave  and  LOS  communication  channels.  The  DSPT  provides  a  limited 
operating  system  interface.  (In  the  NRL/UNT  tests,  this  limited  operating  system  interface  was  sufficient  to 
meet  all  of  the  operating  system  demands  of  the  target  communication  software.)  During  the  development 
of  the  NFSE  System  software,  the  DSPT  shall  be  the  primary  tool  for  coixlucting  in-lab  tests  of  this  sys¬ 
tem.  The  DSPT  software  shall  be  maintained  under  the  RCS  system. 

7.4.1.3.2  Hardware  and  Firmware  Items 

Hardware  items  needed  in  support  of  the  software  engineering  effort  are  listed  in  section  7.3.2.3. 

7.4.133  Proprietary  Nature  and  Government  Rights 

All  software  developed  for  the  NFSS  is  the  property  of  the  govenunent  and  shall  be  delivered 
without  any  restrictions  on  its  use. 

7.4.13.4  Installation,  Control,  and  Maintenance 

NRL  Code  SS21  is  responsible  for  installing,  controlling,  and  maintaining  the  NFSE  System  soft¬ 
ware. 
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lAJ,  Software  Standards  and  Procedures 


7.4^.  1  Software  Development  Techniques  and  Methodologies 

MIL-STD-2167A  is  being  used  as  a  guide  in  (veparing  the  documentation  for  the  NFSE  System. 
Object-oriented  programming  (OOP)  is  the  methodology  being  used  for  code  development.  In  addition,  an 
effort  is  being  made  to  include  some  of  the  techniques  of  formal  methods  in  the  software  specification 
phase  of  the  NFSE  System  development 

7.4.2.2  Software  Development  Hies 

Prior  to  the  held  tests,  NRL  shall  perform  in-lab  tests  of  each  CSCl.  The  results  of  this  activity 
shall  be  placed  in  the  Software  Development  Files  (SDF)  for  that  CSCI.  Plans  for  the  creation  and  mainte¬ 
nance  of  SDFs'  their  formats  and  contents,  and  the  procedures  for  maintaining  them,  is  yet  to  be  deter¬ 
mined. 

7.4.2.3  Design  Standards 

Object-oriented  design  (OOD)  is  the  primary  design  standard  for  the  NFSE  System  software. 

7.4.2.4  Coding  Standards 
TBD 

7.43  Non«deveiopmental  Software 
See  section  7.4. 1.3.1. 

7.5  Formal  Qualification  Testing 

7.5.1  Organization  and  Resources  •  Formal  Qualification  Testing 
TBD 

7.53  Test  Approach/Philosophy 

The  Network  Controller  CSCI  will  be  tested  separately.  The  Link  Controller  CSCI  will  be  tested 
together  with  the  Network  Controller,  and  finally,  the  System  Controller,  Network  Controller,  and  Link 
Controller  will  be  tested  together. 

7.53  Test  Planning  Assumptions  and  Constraints 

In-lab  testing  is  beir^  planned  under  the  assumption  that  no  modems,  RF  equipment,  or  NRaD 
BLC  hardware  or  software  will  be  available. 
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7.6  Software  Product  Evaluations 


7.6.1  Organizational  Structure  •  Software  Product  Evaluations 

See  section  7.3. 1.3. 

7.6J  Software  Product  Evaluations  Procedures  and  Tools 
TBD 

7.7  Software  Configuration  Management 

See  se^on  7.3.9. 

7.8  Other  Software  Development  Functions 

Not  applicable. 

7.9  Notes 

None. 

7.10  Revisions  to  Section  7 

None. 
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8.  SOFTWARE  REQUIREMENTS 


This  section  serves  as  a  Software  Requirements  Specification  (SRS)  for  each  CSCI  of  the  NFSE 

System. 

8.1  Network  Controller  (NC)  CSCI 

8.1.1  Scope 

8. 1.1.1  Identification 

This  section  describes  the  software  requirements  for  the  Network  Controller  (NC).  which  is  a 
CSCI  of  the  NFSE  System. 

8.1.1.2  NC  Overview 
See  Section  6.4.2.I.I. 

8. 1.1.3  Subsection  Overview 

Section  8.2  specifies  the  engineering  and  qualification  requirements  for  the  Network  Controller 

CSCI. 

8.U  Applicable  Documents 
See  Section  3. 

8.U  En^neering  Requirements 

8.13.1  NC  External  Interface  Requirements 

Hgure  11  shows  the  modules  with  udiich  the  NC  interacts  and  identifies  the  interfaces  through 
which  these  interactions  take  place.  The  specifications  of  these  interfaces  are  given  in  section  9.3. 

8.133  NC  Capability  Requirements 

The  Network  Controller  shall  implement  the  following  specified  c^)abilities. 

8.13.2.1  NC«to-NC  Communication  (NC.COM)  Requirement 

The  NC_COM  capability  of  the  NC  CSCI  shall  provide  the  following  communication  and  commu¬ 
nication-related  services. 
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Node  i 


Node} 


Figuie  11  NC  external  interface  rcquiiements. 

•  Point-to-point  message  service  -  This  service  shall  provide  a  means  of  sending  messages  from  an  NC 
pon  at  one  node  to  the  designated  destination  node  and  NC  port  Once  the  NC^COM  function  accepts  a 
message  for  delivery,  it  shall  deliver  the  message  to  the  destination  node  with  an  average  delay  that 
shall  not  exceed  the  hop  count  times  the  frame  duration,  where  the  hop  count  is  the  number  of  relay 
transmissions  needed  to  reach  the  destination.  Duplicate  messages  shall  be  detected  and  discarded. 

•  Broadcast  message  service  -  This  service  shall  provide  a  means  of  sending  messages  from  an  NC  port  at 
one  node  to  a  designated  port  at  every  other  node.  Once  the  NC^COM  function  accepts  a  message  for 
delivery,  it  shall  deliver  the  message  to  the  destination  nodes  with  an  average  delay  that  shall  not  exceed 
the  hop  count  times  the  frame  duration,  where  the  hop  count  is  the  number  of  relay  transmissions 
needed  to  reach  a  destination.  Duplicate  messages  diall  be  detected  and  discarded. 

•  Local  message  service  -  This  service  shall  provide  a  means  of  sending  messages  from  an  NC  port  at  one 
node  to  the  designated  port  at  any  node  that  is  directly  connected  to  the  source  node. 

•  Network  connectivity  learning  service  -  This  service  shall  provide  a  measure  of  both  short-term  and 
long-term  link  qualities  for  all  possible  links  in  the  network. 

■  Performance  monitoring  service  -  This  service  shall  provide  a  means  for  gathering  and  reporting  NC 
performance  data. 

A  message  should  not  be  greater  than  MAX.USER.DATA.  User  traffic  that  exceeds  MAX_- 

USER.DATA  should  be  segmented  and  reassembled  by  higher-level  protocols. 

Tte  NC_COM  capability  will  be  obtained  by  modifying  the  NC  used  by  NRL  in  the  UNT  project 

Network  Frequency  Selection  Service  (NFSS)  Requirement 

See  section  5.3.2.I.I.I. 
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8.13.3  NC  Internal  Interfaces 


Figure  12  shows  the  interfaces  internal  to  the  NC.  These  interfaces  are  described  in  the  following 
subsections. 


Figure  12  NC  internal  interfaces 


8.13.3.1  Internet  Protocol  (IP)  Interface  (IF.IP) 

The  IF_IP  interface  is  the  vx Works  network  interface  driver  for  the  NFSE  System’s  internal  net¬ 
work.  The  requirements  for  this  driver  are  given  in  [12]. 

8.13.33  NFSS  to  NC.COM  Interface  (IF_NC.COM.NFSS) 

The  IF.NC.COM.NFSS  interface  connects  the  Network  Frequency  Selection  Service  to  the  com 
munication  services  (NC.COM)  that  it  needs  to  perform  its  task. 

8.1.4  Qualification  Requirements 

In-lab  demonstrations  shall  be  used  to  verify  that  the  Network  Controller  CSCl  implements  the 
capabilities  described  in  section  8. 1.3.2. 

8.13  Preparation  for  Delivery 

The  NFSS  source  code  shall  be  delivered  in  hard  copy  form. 

8.1.6  Notes 
None. 


48 


8.2  Link  Controller  (LC)CSCI 


8.Z1  Scope 

8.2.1.1  Identification 

This  section  describes  the  software  requirements  for  die  Link  Controller  (LC),  which  is  a  CSCI  of 
the  NFSE  System. 

8JL1.2  LC  Overview 

See  Section  6.4.2.2.I. 

8.2.1.3  Subsection  Overview 

Section  8.2  specifies  the  engineering  and  qualification  requirements  for  the  Link  Controller  CSCI. 

8.2.2  Applicable  Documents 

See  Section  3. 

8.23  Engineering  Requirements 

8.23.1  LC  External  Interface  Requirements 

Hgure  13  shows  the  external  modules  with  which  the  LC  interacts  and  identifies  the  interfixxs 
through  which  these  interactions  take  place.  These  interfaces  are  specified  in  section  9. 

8.233  LC  Capability  Requirements 

8.23.2.1  LC>to-LC  Communication  (LC.COM)  Requirement 

The  LC  shall  provide  communication  with  other  LCs  that  are  within  direct  communication  range 
and  provide  the  lower  level  communication  services  required  by  the  NC.  Specific  capabilities  provided  by 
the  LC.COM  function  are  as  follows. 

*  Provide  time*synchronous,  block-oriented  communication  service  to  die  NC  that  allows  communica¬ 
tion  between  nodes  that  are  directly  connected.  (The  smallest  unit  of  data  exchange  between  the  LC  and 
NC  shall  be  a  block.) 

•  Provide  indicating  to  the  NC  whedier  a  block  was  received,  and  if  it  was  received,  indicate  whedier 

it  was  received  without  errors. 

*  F-^ch  block  shall  be  capable  of  holding  M_BLOCKSIZE  bytes  of  data  from  the  NC  (not  including 
checksum  bytes  added  by  the  LC). 

•  When  the  NC  delivers  a  blodt  of  data  to  the  LC  it  tiiall  indicate  the  time  at  whidi  die  block  transmis¬ 
sion  is  to  occur. 
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Figure  13  LC  external  interface  lequiiemefitt. 


•  An  LC  shall  transmit  a  block  of  data  within  10  milliseconds  of  its  scheduled  transmission  time. 

•  A  block  received  from  die  modem  by  the  LC  shall  be  delivered  to  the  NC  within  270  milliseconds  of 
the  reception  of  the  entire  block  by  the  LC. 

•  Blocks  shall  be  delivered  to  the  LC  from  the  NC  in  time-of-transmission  order. 


The  LC.COM  module  shall  also  provide  the  NC  with  the  capability  to  exercise  the  following  con¬ 
trol  over  the  attached  transmitter  and  receiver. 

•  Set  transmit  frequency  at  given  time. 

•  Set  receive  frequency  at  given  time. 


8.23.2J1  Node  Uming  (ND.TIME)  Requirement 

The  LC  shall  provide  precise  time  of  day  and  1  pulse-per-millisecond  signals  to  die  NC. 

The  LC  shall  schedule  the  sequencing  of  events  and  provide  the  required  data  manipulation  to 
drive  the  RF  hardware. 

9,233  LC  Internal  Interfaces 


The  internal  interfaces  between  the  LC  functional  capabilities  are  identified  in  figure  14. 
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Figure  14  LC  internal  interface  requirements. 

8.2.4  Qualification  Requirements 

In-lab  demonstrations  shall  be  used  to  verify  that  the  Link  Controller  CSCI  implements  the  capa¬ 
bilities  described  in  section  8.2.3.2. 

8.2.5  Preparation  for  Delivery 

Not  applicable. 

8.2.6  Notes 

None. 

8.3  System  Controller  (SC)  CSCI 

8.3.1  Scope 

8.3.1.1  Identification 

This  section  describes  the  software  requirements  for  the  System  Controller,  which  is  a  CSCI  of  the 
NFSE  System. 

83.1.2  csa  Overview 
See  Section  6.4.2.3.I. 

83.1.3  Subsection  Overview 

Section  8.2  specifies  the  engineering  and  qualification  requirements  for  the  System  Controller 

CSCI. 

833  Applkable  Documents 
See  Section  3. 
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S.33  Engineering  Requirements 


8.33.1  SC  External  Interface  Requirements 


Figure  15  shows  the  external  modules  with  which  the  System  Controller  interacts  and  identifies 
the  interfiues  through  which  these  interactions  take  place.  These  interfaces  are  specified  in  section  9. 


Figure  IS  SC  external  interface  requirements. 


8.33.2  SC  Capability  Requirements 

8.33.2.1  System  Performance  Ardiiving  (SC.ARCHIVE)  Requirement 

The  System  Controller  shall  provide  fix  the  logging  of  NFSE  System  performance  data  to  disk 
file. 

8.33.23  System  Mom'tor  and  Control  (SC_MON)  Requirement 

The  System  Controller  shall  (xovide  a  system  monitoring  and  control  capability  that  is  accessible 
by  the  System  Operator.  The  interface  to  this  service  shall  provide  the  operator  with  a  means  of  ascertain¬ 
ing  the  status  of  the  NFSE  System  and  starting  and  stopping  the  system. 

833.3  SC  Internal  Interfaces 

There  are  no  internal  intnfaoes  between  the  System  Controller  functional  capabilities. 

8.3.4  Qualification  Requirements 

In-lab  demonstrations  shall  be  used  to  verify  that  the  System  Controller  CSCI  implements  the 
ctqnbilities  described  in  section  8.3.3.2. 
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8.3J  Preparation  for  Delivery 
Not  applicable. 

8.3.6  Notes 
None. 

8.4  Revisions  to  section  8 
None. 
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9.  INTERFACE  REQUIREMENTS  SPECIFICATION 


9.1  Scope 

9.1.1  Identification 

This  section  serves  as  the  Interface  Requirements  Specification  (IRS)  for  the  NFSE  System. 

9.U  System  Overview 

See  section  S.1.2  on  page  13. 

9.13  Section  Overview 

This  section  specifies  the  requirements  for  the  interfaces  between  the  CSCIs  that  make  up  the 
NFSE  System. 

9.2  Applicable  Documents 

See  Section  3 

9.3  Interface  Specification 

9.3.1  Interface  Diagrams 

Rgure  16  shows  the  interface  diagram  for  the  NFSE  System.  The  interfaces  IF_LC_GPS, 
IF_LC_RCTL,  IF_LC_XCTL,  and  IF_LC_NOSC  connect  the  NFSE  System  to  its  external  environment. 
Those  interfaces  are  specified  in  section  6.4.2.2.3.  This  IRS  covers  the  other  interfaces  shown  in  figure  16. 
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Node  I 


Node'] 


Table  27  gives  a  listing  of  the  NFSE  System  interfaces  that  are  specified  in  this  IRS. 
Table  27:  Listing  of  NFSE  System  interfaces  specified  in  *fae  IRS. 


Interface  Descriptor 

Interface  Identifier 

LX^-to-LC  Peer  Interface 

IF_LC_LC 

Network  Controller/Link  Controller  Interface 

IF_NC_LC 

NC-to-NC  Peer  Interface 

IF_NC_NC 

Operator/System  Controller  Interface 

IF_OP_SC 

System  Ctmtrollec/Unk  Controller  Interface 

IF_SC_LC 

System  Ctmtroller/Network  Controller  Interface 

IF.SC.NC 
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9.3.2  Network  Contfoller/Link  Controller  Interface  (IF_NC_LC) 


9.3.2. 1  Interface  Requirenwnts 

The  NC  and  LC  CSCIs  execute  concurrently.  The  LC  executes  on  the  M333NRL  board  and  inter¬ 
faces  via  shared  memory  board  M224NRL  to  the  NC  Real-Time  processor  board  NC_RT  (Proc  #1).  The 
interface  requirements  for  IF_NC_LC  are  similar  to  the  NC/LC  interface  described  in  [10]. 

All  communications  between  the  NC  and  LC  take  place  via  queues  and  data  buffers  located  on  the 
M224NRL  shared  memory  board.  The  NC  and  LC  are  each  responsible  for  maintaining  its  own  queues 
and  buffers  and  for  the  movement  of  data  between  its  own  local  memory  and  shared  memory  when 
required.  Commands  are  passed  between  the  NC  and  LC  via  command  queues  which  are  constantly  moni¬ 
tored.  When  a  command  from  the  NC  has  been  detected,  the  LC  immediately  (within  1  ms)  copies  the 
command  parameters  to  it  local  memory.  The  LC  performs  a  validity  test  on  the  command  to  ensure  it  is 
valid  and  will  reject  it  if  it  is  not.  Rejected  commands  are  immediately  returned  to  the  NC  with  a  suitable 
error  code.  The  command  queue  is  then  reset  to  “idle”  signaling  the  NC  that  the  command  has  been  pro¬ 
cessed  and  the  queue  slot  is  again  available  for  use.  Commands  from  the  LC  to  the  NC  are  f^ocessed  in  the 
same  maimer  by  the  NC. 

9.3JS.2  Data  Requirements 

The  data  requirements  for  the  IF_NC_LC  interface  are  described  in  file  common.h,  which  appears 

in  (91. 

9,33  Operator/System  Controller  Interface  (IF_OP_SC) 

This  provides  the  man-machine  interface  for  the  system  operator. 

9.33.1  Interface  Requirements 

The  console  screen  shall  provide  the  windows  shown  in  figure  17.  The  windows  labeled  “NC_RT’ 
and  “NC_NRT"  connea  to  the  MVME  135  NC_RT  and  NC_NRT  boards,  respectively,  of  the  BLC  chas¬ 
sis.  These  two  windows  allow  the  operator  to  interact  with  these  two  boards  via  the  VxWorks  shell.  The 
window  labeled  “M333NRL”  is  a  Unix  “tip”  window  that  cotuiects  to  the  M333NRL  board  on  the  BLC 
chassis.  This  window  allows  the  operator  to  interact  with  the  monitor  program  stored  on  the  M333NRL 
board.  The  window  labeled  “SC”  is  for  interacting  with  the  operating  system  of  the  NFSE  System  console. 

9.33.2  Interface  Commands 

The  operator  can  issue  VxWorks  shell  commands  in  the  windows  labeled  “NC_RT”  aiKl 
“NC.NRT",  Unix  shell  commands  in  the  window  labeled  “SC”,  and  MVME333Bug  commands  in  *e 
window  labeled  “M333NRL”. 

933JL1  VxWorks  Shell  Commands 

The  VxWorks  sheU  commands  are  described  in  the  Wind  River  Systems  documentation  that 
describes  the  VxWrxks  system.  Ihe  operator  can  obtain  on-line  help  for  a  specific  command  by  typing 
“vwman  <command>”. 
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933.2  Unix  Commands 

The  Unix  commands  are  described  in  the  numerous  books  on  this  operating  system.  The  operator 
can  obtain  on-line  help  for  a  specific  command  by  typing  “man  <command>”. 

9.33.2 J  MVME333Bug  Commands 

The  MVME333Bug  commands  are  described  in  the  manual  that  accompanies  the  MVME333Bug 
proms.  The  operator  can  obtain  on-line  help  by  typing  “HE”.  The  HE  (help)  command  displays  all  com¬ 
mands  available  in  MVME333Bug. 


Hgure  17  Startup  display  on  System  Controller  screen. 


93.4  System  Controller/Link  Controller  Interface  (IF.SC.LC) 

The  IF_SC_LC  interface  is  an  RS232  connection  between  Port  A  on  the  Sun  console  and  Port  1  on 
the  MVME705,  vdiich  serves  as  a  transition  board  for  the  M333NRL  board. 


9.3.5  System  Controller/Network  Controller  Interface  (IF_SC_NC) 


The  IF_SC_NC  interface  is  an  ethemet  to  which  both  the  SC  and  NC  are  attached.  The  SC  is  con¬ 
nected  directly  to  the  ethemet.  while  the  NC  is  conneaed  to  the  ethemet  via  the  LANCNTR  board. 

9.3.6  NC-to-NC  Peer  Interface  (IF_NC_NC) 

9.3.6.1  Interface  Requirements 

Network  Controllers  on  different  nodes  conununicate  with  each  other  via  synchronous  and  asyn¬ 
chronous  mes.«sages  Synchronous  messages  are  sent  at  precisely  known  times.  Asynchronous  messages  are 
subject  to  queuing  delays,  and  therefore,  the  precise  time  that  they  will  be  transmitted  is  not  predeter¬ 
mined. 

9.3.6.2  Data  Requirements 

The  formats  of  synchronous  and  asynchronous  messages  are  given  in  section  11.3.4. 

9.3.7  LC-to-LC  Peer  Interface  (IF_LC_LC) 

i.inif  Controllers  on  different  nodes  communicate  with  each  other  via  bursts  of  6  blocks  that  con¬ 
tain  M.BLKSIZE  bytes  of  upper-layer  data  plus  a  2-byte  (first  five  blocks)  or  1-byte  (sixth  block)  block 
checksum.  Sec  references  [9]  and  [10]  for  a  discussion  of  the  checksum  procedure. 

9.4  Quality  Assurance 

TBD 

9.5  Preparation  for  Delivery 

None. 

9.6  Notes 

None. 

9.7  Revisions  to  Section  9 

None. 
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10.  SOFTWARE  DESIGN 


This  section  serves  as  the  Software  Design  Document  (SDD)  for  all  of  the  CSCIs  that  make  up  the 
NFSE  System. 

10.1  Software  Design  for  the  Network  Controller  (NC)  CSCl 

10.1.1  Scope 

10.1.1.1  Identification 

Section  10. 1  covers  the  software  design  for  the  Network  Controller  (NC)  CSCI,  which  is  a  compo¬ 
nent  of  the  Network  Frequency  Selection  Experiment  System. 

10.1.1.2  System  Overview 

See  section  S.1.2  on  page  13. 

10.1.1.3  Subsection  Overview 

Section  10.1  describes  the  design  of  the  NC  CSCI. 

10.1.2  Referenced  Documents 
See  Section  3. 

lO.U  Preliminary  Design 

10.13.1  NC  Overview 

10.13.1.1  NC  Architecture 

Figure  18  shows  the  NC  architecture.  The  NC  is  organized  as  two  components  ~  a  non-real-time 
component  NC.NRT  and  a  real-time  component  NC_RT.  Each  of  these  components  operates  on  a  separate 
processor  board.  The  NC_RT  handles  those  tasks  that  are  time  critical.  The  remaiiung  tasks  are  executed 
out  of  the  NC_NRT  processor.  Within  the  NC  are  two  major  components  -  the  NFSS  module  and  the 
NC_COM  module.  The  NFSS  implements  the  Network  Bequency  Selection  Service,  while  the  NC_COM 
module  inipieinenf.«8  the  communication,  monitoring,  and  other  services  required  of  the  NC.  For  the  most 
part,  the  NC_COM  design  is  identical  to  the  NC  design  that  was  used  by  NRL  in  the  UNT  project  The 
major  addition  to  the  present  NC  design  is  the  Network  Frequency  Selection  Service  (NFSS)  ftmctionality. 
A  minor  addition  is  the  inclusion  of  the  IP  Connection  function,  which  enables  internetting  between  the 
NFSE’s  internal  network  and  other  networks.  Figure  35  also  shows  the  key  interfaces  internal  to  the  NC. 

Additional  riming  for  the  NC  for  operation  with  the  NFSE  System’s  internal  network  is  given  in 
figure  19.  During  die  period  between  activations  of  the  NFSS,  time  is  divided  into  Reorganization  Periods 
of  Anation  Tgp.  These  ate  furdier  divided  into  frames  Fj,  which  in  turn  are  subtfivided  into  transmission 
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Bgure  18  NCnctutediiie  showing  CSCs,  key  interfices,  and  die  target  hardware. 


slots  S'j.  la  the  event  that  a  whole  number  of  reorganization  periods  does  not  ht  exactly  into  the  interval 
between  activations  of  the  NFSS,  a  time-hll  period  has  been  added  The  number  of  frames  per  reorga¬ 
nization  period  is  given  by  Np, . 


time 

Figure  19  Additional  system  timing  for  q)eration  with  NFSE  System's  internal  network. 


10.U.2  NC  Design  Description 

Hie  NC  CSCI  is  fiiither  decomposed  into  computer  software  components  (CSC),  which  are 
described  in  this  subsection.  The  computer  software  components  of  the  NC  are  also  shown  figure  55. 

IO.U.2.1  Network  Connectivity  Learning  (NC.NCL)  CSC 

The  NC_NCL  is  used  to  determine  the  status  of  local  connectivities,  to  identify  ''reiiable"  bidirec¬ 
tional  links  between  the  host  node  and  its  neighbors,  and  to  disseminate  link  quality  information  to  all 
nodes  in  the  network. 

The  NC_NCL  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2. 1. 

10.13.2 J  Network  Structuring(NC_NS)  CSC 

The  NC_NS  is  used  to  organize  the  nodes  into  a  Linked  Ouster  Architecture,  as  described  in  [3]. 

The  NC_NS  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2.I. 

10.13.23  Dransmitter  Control  (NC.XC)  (^C 

This  CSCI  determines  when  a  transmitter  is  allowed  to  transmit,  and  it  {xovides  an  interface  to  the 
remote  control  functions  of  the  transmitter. 
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The  NC_XC  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2. 1. 

10.13.2.4  Receiver  Control  (NC_RC)  CSC 

This  CSCI  {Hovides  an  interface  to  the  remote  control  functions  of  the  receiver. 

The  NC_RC  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2. 1. 

10.13.23  Tltuisinit  Buffers  Management  (NC.TBM)  CSC 

The  NC_TBM  has  several  functions  •  it  manages  the  storage  of  messages  awaiting  transmission,  it 
packs  messages  into  transmit  buffers,  and  it  generates  aiKi  inserts  sequence  numbers  in  relay  message 
headers.  The  messages  stored  by  the  NC.TBM  may  originate  in  higher  layers  or  they  may  originate  locally 
in  other  NC  CSCs.  Also,  it  manages  the  storage  of  pointers  to  messages  that  are  being  relayed.  Relay  mes¬ 
sages  have  their  own  message  store  facility  based  in  the  NC_RBM  (Receive  Buffers  Management)  CSC. 
however,  the  TBM  acce-sses  relay  messages  via  queues  of  pointers  that  it  maintains. 

The  NC.TBM  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2. 1. 

10.13.2.6  Receive  Buffers  Management  (NC.RBM)  CSC 

The  Receive  Buffers  Manager  checks  each  block  of  an  incoming  packet  for  block  errors  ^  com¬ 
putes  a  link  quality  index  (LQI)  value  for  each  link,  unpacks  messages  from  each  receiver's  Receive  Buffer 
and  forwards  each  message  to  the  ^jptopriate  destination  within  the  NC.  The  NC_RBM,  also,  prevents 
duplicate  messages  from  being  delivered  to  the  upper  layer  and  removes  relay  messages  from  relay  queues 
(i.e.,  from  the  NC_RBM  message  store)  that  have  exceeded  their  time-to-live. 

The  NC.RBM  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2. 1. 

10.13.2.7  Congestion  Control  (NC_CC)  CSC 

The  function  of  Congestion  Control  is  K)  [»event  the  degradation  of  network  performance  that  can 
occiu'  when  traffic  levels  exceed  that  which  the  internal  network  can  effectively  handle. 

The  NC^CC  CSC  suf^xnts  the  network  communication  service  requirements  given  in  Section 

5.3.2.I. 


1.  Checksiiins  are  computed  by  the  Link  CooODller  and  the  results  sent  to  the  Network  Controller  for  use  in  deter- 
mining  message  enois  and  link  quality. 


10.13.2^  Message  Router  (NC.MR)  CSC 

The  function  of  the  Message  Router  (NC_MR)  is  to  determine  whether  the  host  node  should  relay 
an  asynchronous  message  and  to  forward  asynchronous  messages  destined  for  the  host  node  to  the  appro¬ 
priate  destination  port 

The  NC.MR  supports  the  network  communication  service  requirements  given  in  Section  S.3.2.1. 

10.1  Network  Manager  (NC_NM)  CSC 

The  Network  Manager  maintains  the  local  performance  database.  NC_NM  is  responsible  for  mon¬ 
itoring  system  performance,  and  it  is  intended  to  serve  as  an  interface  for  purposes  of  monitoring  and  con¬ 
trolling  the  operation  of  the  internal  network  and  other  components  of  the  NFSE  System. 

The  NC_NM  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2. 1. 

10.13.2.10  Network  Frequency  Selection  Service  (NC.NFSS)  CSC 

This  CSC  implements  the  network  frequency  selection  service  ^dfied  in  section  S.3.2.1. 1.1. 

10.13.2.11  NC  Timing  Control  (NC.TC)  CSC 

This  CSC  implements  the  timing  structure  shown  in  Figure  7.  It  also  provides  a  facility  for  sched¬ 
uling  procedure  calls  and  subsequently  calling  those  procedures  at  the  appropriate  times. 

The  NC_TC  supports  the  network  frequency  selection  service  and  the  network  communication 
service  requirements  given  in  Section  5.3.2. 1. 

10.13.2.12  NC_RT  System  Startup  (NC_RT_SU)  CSC 

This  CSC  is  the  first  NC  software  that  is  executed  on  the  NC_RT  processor  board  at  system  star¬ 
tup,  and  it  is  responsible  for  starting  the  rest  of  the  NC_RT  software. 

The  NC_RT_SU  supports  the  network  frequency  selection  service  and  the  network  communica¬ 
tion  service  requirements  given  in  Section  5.3.2. 1. 

10.13.2.13  NC.NRT  System  Startup  (NC_NRT_SU)  CSC 

This  CSC  is  the  first  NC  software  that  is  executed  on  the  NC_NRT  processor  board  at  system  star¬ 
tup,  and  it  is  responsible  for  starting  the  rest  of  the  NC_NRT  software. 

The  NC_NRT_SU  supports  the  network  fi^equency  selection  service  and  the  network  communica¬ 
tion  service  requirements  given  in  Section  5.3.2. 1. 
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10.1  J.2.14  IP  Connection  (NC_IP_CONN)  CSC 


This  CSC  implements  the  connection  to  the  Internet  Protocol  (IP)  via  the  Operating  System  inter¬ 
face. 


The  NC_IP_CONN  supports  the  network  communication  service  requirements  given  in  Section 

5.3.2. 1. 

10.13.2.15  LC  Connection  (NC_LC_CONN)  CSC 

This  CSC  implements  the  NC’s  part  of  the  IF_NC_LC  interface. 

The  NC_LC_CONN  supports  the  network  frequency  selection  service  and  the  network  communi¬ 
cation  service  tequirements  given  in  Section  5. 3.2.1. 

10.13.2.16  Real-time  Output  Server  (NC_RTO_SV)  CSC 

This  CSC  allows  concurrent  file  output  capability  in  a  multiprocessor,  real-time  system. 

The  NC_RTO_SV  supports  the  network  firequency  selection  service  and  the  network  communica¬ 
tion  service  requirements  given  in  Section  5.3.2.I. 

10.13.2.17  NC  Sim++  Interface  (IF.SIM)  CSC 

The  IF.SIM  CSC  emulates  a  subset  of  the  Sim-M-  software  from  Jade  Simulations  International 
(JSI)  on  a  vxWorks  target  MVME135A  CPU. 

The  IF.SIM  CSC  su{^rts  the  network  frequency  selection  service  and  the  network  communica¬ 
tion  service  requirements  given  in  Section  5.3.2.I. 

10.13.2.18  NC  DSPT  Interface  (1F_DSPT)  CSC 

The  IF_DSPT  CSC  emulates  a  subset  of  the  DSPT  software  fiom  NRL  on  a  vx Works  target 
MVME135ACPU. 

The  IF_DSPT  CSC  supports  the  network  frequency  selection  service  and  the  network  communica¬ 
tion  service  requirements  given  in  Section  5.3.2. 1. 

10.13.2.19  TVaffic  Source/Sink  (NC_SRC_SNK)  CSC 

This  CSC  provides  a  source  and  sink  of  traffic  in  order  to  perform  built-in  tests  of  the  NFSE  Sys¬ 
tem's  internal  network. 

The  NC_SRC_SNK  supports  the  network  communication  service  requirements  given  in  Section 

5.3.2.1. 
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10.1.4  Detailed  Design 


10.1.4.1  Network  Connectivity  Learning  (NC_NCL)  CSC 

The  NC_NCL  CSC  is  structured  as  two  component  CSUs  -  the  Periodic  Probing  Algorithm  (PPA) 
and  the  Network  Connectivity  Learning  Algorithm  (NCLA). 

10.1.4.1.1  Periodic  Probing  Algorithm  (PPA)  CSU 

10.1.4.1.1.1  Periodic  Probing  Algorithm  Deagn  Specification/Constraints 

The  purpose  of  the  PPA  is  to  provide  a  periodic  check  of  a  node’s  direct  connectivities  with  other 
nodes  in  the  network  and  to  identify  ^  report  reliable  bidirectional  links  to  its  neighbors. 

10.1.4.1.1.2  Periodic  Probing  Algorithm  Design 

Each  node  can  discover  who  its  neighbors  are  by  the  process  of  probing.  When  a  probe  message  is 
broadcast,  every  other  node  replies  with  either  an  acknowledgmem  (ACK)  or  a  negative  acknowledgment 
(NAK)  depending  on  whether  or  not  it  received  the  probe  message.  A  simple  strategy  for  effecting  such  a 
probing  by  every  node  is  to  set  up  two  TDMA  frames  for  controlling  the  transmission  of  probe  and 
acknowledgment  messages.  In  this  approach,  nodes  are  numbered  from  1  to  N  and  each  node  is  assigned 
its  correspondingly  numbered  transmission  slot,  once  in  each  frame.  The  slot  assignments  are  included  in 
the  Communication  Plan  (COMHLAN),  which  is  available  to  every  node. 

During  frame  1  each  node  broadcasts  its  probe  message,  which  includes  the  ACKs  and  NAKs  of 
previously  transmitted  probe  messages.  During  frame  2  each  node  ACKs  or  NAKs  frame  1  probe  mes¬ 
sages  sent  since  its  own  frame  1  transmission.  The  formats  of  these  ’’synchronous”  messages  are  ^wn  in 
figures  59  and  60. 

Each  node  maintains  information  about  the  status  of  all  of  its  incoming  links.  This  information 
relates  to  both  the  results  of  the  periodic  probing  and  to  the  number  of  192-bit  blocks  (see  section  1 1.3.3. 1 
for  a  discussion  of  blocks)  received  correctly  over  the  link  since  the  last  probe.  In  subsequent  sections  we 
provide  details  of  how  this  status  is  measured.  Here  it  is  only  necessary  to  point  out  that  link  quality  is 
specified  in  terms  of  a  Link  Quality  Index  (LQI),  which  can  take  on  the  values  0  (lowest  quality)  to  3 
(highest  quality).  LQ/j  j  gives  the  quality  of  the  link  from  node  j  to  node  i.  A  node  announces  the  LQI  val¬ 
ues  of  its  own  incoming  links  as  part  of  the  Periodic  Probing  Algorithm. 

The  PPA  also  identifies  reliable,  bidirectional  links  at  a  node  and  broadcasts  this  information  to 
neighboring  nodes.  The  test  that  is  applied  at  node  i  to  ascertain  whether  it  is  bidirectionally  connected  to 
node  j  is  slightly  different  depending  on  whether  j  is  greater  than  or  less  than  i. 

If  i<y,  node  i  considers  a  link  to  node  j  to  be  a  reliable,  bidirectional  (RB)  link  and  considers  node 
;  to  be  a  RB-neighbor  (RBN)  if: 


LQI LQI, 
and 

LQIj^i^LQI, 


(EQIO) 

(EQll) 
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and  node  i  and  node  j  received  each  other's  probes.^ 

If  j<i,  node  ( considers  a  link  to  node  j  to  be  a  reliable,  bidirectional  (RB)  link  and  considers  node 
>  to  be  a  RB-neighbor  if: 


LQI^j>LQI, 

(EQ  12) 

LQIjj^LQI^ 

(EQ13) 

and  node  i  received  notte  j's  frame  2  transmission,  which  indicated  that  node  j  was  RB-Iinked  to  node 
i.^The  reason  for  using  a  slightly  different  criterion  in  this  last  step  when;<i  is  so  that  both  i  and>  agree  on 
whether  the  link  between  them  is  an  RB-link.  Above,  is  that  value  of  LQl  that  defines  a  reliable,  uni¬ 
directional  link.  As  part  of  its  frame  2  transmission,  each  node  transmits  a  vector  identifying  those  nodes  to 
which  it  has  RB-links. 

Pseudocode  for  the  PPA  is  shown  in  Figure  20. 

Use  own  link_quality_vector  (from  RBMA  measurements) 

Wait  for  one  of  the  following  events  and  process  as  indicated: 

Case  start_of_reorgani2ation_epoch: 
probea_heard= ( 0 , . . . ,  0 ) ; 

link_quality_matrix=null  matrix+own  link_quality  vector; 
reliable_2way_connectivity  matrixsnull  matrix; 

Case  tran8mit_in_framel : 

Send  probes.heard  vector  and  own  link_quality  vector; 

Case  received_freutiel_transmis8ion_front_node_j : 
probes_heard I j ] *1 ; 

Store  received  link_quality  vector  into  row  j  of  link  quality  matrix; 
if  (i<j  and  link  i, j  is  reliable  and  bidirectional) 
reliable_2way_connectivity ( i , j ] =1 ; 

Case  transmit_in_frame2 ; 

Send  probes_heard  and  own  reliable_2way_connectivity  vectors; 

Case  received_f rame2_transmission_from_node_j : 

Store  received  reliable_2way_connectivity  vector  row  j  of  matrix; 
if  (j<i  and  link  i,j  is  reliable  and  bidirectional) 
reliable_2way_connectivity [ i ,  j  I  =1 ; 

Figure  20  Pseudocode  for  the  Period^.  Aobing  Algoiithm  at  node  i. 


2.  When  the  netwoik  first  starts  up,  (nlydus  last  comhoon  is  tested. 

3.  When  the  network  first  starts  up,  <mly  this  last  cooditioo  is  tested. 
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10.1.4.1J!  Network  Connectivity  Learning  Algorithm  (NCLA)  CSU 


10.1.4.1^.!  Network  Connectivity  Learning  Algorithm  Design  Specification/Constraints 

During  frame  1  of  the  reorganization  epoch,  nodes  report  on  the  quality  of  reception  over  all 
incoming  links  since  the  last  reorganization.  The  purpose  of  the  NCLA  is  to  relay  this  information  to  all 
nodes  in  the  network. 

10.L4.U.2  Network  Connectivity  Learning  Algorithm  Design 

The  Periodic  Probing  Algorithm  (PPA)  is  resporisible  for  the  first  transmission  of  every  link  qual¬ 
ity  report.  Both  the  NCLA  and  PPA  read  the  link  quality  information  sent  in  frame  1  by  the  PPA;  thereafter, 
the  NCLA  handles  subsequent  retransmissions. 

The  link  quality  vectors  could  be  sent  as  separate,  broadcast  messages,  which  the  network  delivers 
to  all  nodes.  Such  an  approach  would  work,  but  it  is  inefficient  to  send  lots  of  small,  broadcast  messages. 
Moreover,  some  of  this  information  may  be  unchanged  from  epoch  to  epoch,  and  therefore  it  need  not  be 
retransmitted.  The  NCLA  avoids  these  inefficiencies. 

The  format  of  the  data  portion  of  an  asynchronous  local  message  that  contains  link  quality  reports 
is  shown  in  Figure  21.  Several  reports  can  be  p^ed  into  one  message.  Each  report  is  tagged  by  the  most 
recent  epoch  number  ( modulo  ) )  for  which  the  data  applies.  When  a  link  quality 

report  is  received,  the  NCLA  checks  to  see  if  it  represents  newer  and  different  information  than  is  currently 
in  the  node’s  database.  Old  or  unchanged  data  is  not  retransmitted  •  with  one  exception,  which  we  describe 
shortly.  The  NCLA  also  decides  whether  to  retransmit  data  received  over  the  air.  The  NCLA  performs  this 
determination  in  a  way  similar  to  that  used  by  the  Broadcast  Traffic  Routing  Algorithm  (BTRA)  (see  sec¬ 
tion  10.1.4.8.1.2)  to  decide  whether  to  retransmit  a  regular  broadcast  traffic  message. 
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a.  Num.  connectivity  reports  (NCR) 

b.  ID  of  orig.  reporting  node 

c.  Epoch  ID 

d.  LQI  vector 

Additional  connectivity  reports 


NB_NODE_ID 

NB_NODEJD 

nb_ncla_epcx:h 

NB_SINGLE_LQI*N 


} 


NCR 


Data  packet  size  (bits):  NB_NODE_ID+NCR*(NB_NODE_ID+NB_NCLA_EPOCH+NB_SINGLE_LQI*N) 


Figure  21  Format  of  NCLA  data  packet  for  a  seven  node  (N=7)  network. 


An  additional  service  performed  by  the  NCLA  is  to  retransmit  link  quality  information,  received  in 
PPA  transmissions  from  its  immediate  neighbors,  which  has  not  changed  over  long  periods  of  time.  The 
reason  for  doing  this  is  to  prevent  the  case  of  some  nodes  never  learning  full  connectivity  information 
owing  to  missing  one  of  the  NCLA  transmissions  of  its  neighbor.  The  period  of  time  that  must  pass  before 
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a  repon  is  retransmitted  is  determined  by  the  maximum  epoch  number  that  can  appear  in  a  link  quality 
report  When  a  node  transmits  a  link  quality  veaor.  it  saves  a  copy  of  the  epoch  number  that  accompanied 
this  report.  As  newer,  but  otherwise  identical  reports  are  received  as  part  of  the  PPA  transmissions,  poten¬ 
tial  relay  nodes  simply  update  the  epoch  number  for  which  these  link  qualities  apply.  If  the  link  quality 
vector  remains  unchanged  while  the  epoch  number  goes  full  circle  to  the  value  it  had  when  that  report  was 
last  transmitted,  the  report  will  be  marked  as  “not  transmitted”  and  may  be  retransmitted.  If  the  epoch  num¬ 
ber  corresponding  to  a  link  quality  vector  in  a  node's  NCLA  database  remains  unchanged  while  the  epoch 
number  goes  through  a  complete  cycle,  that  link  quality  vector  is  archived,  which  means  that  it  will  never 
be  retransmitted.  Pseudocode  for  the  NCLA  is  given  in  Rgure  22  and  Rgure  23. 


if  report  has  been  superseded  then 
Ignore  the  one  just  received; 
else  if  report  is  a  duplicate  Then 
if  state  !=  sent  then 

Update  nodes_that_heard_report ; 

Update  nodes_that_must_be_sent_to ; 

If  nodes_that_must_be_sent_to  is  empty  AND  state  ==  RELAY  Then 
state  =  SAVE; 

else  if  report  contains  same  connectivities  but  more  recent  epoch  then 
if  t  is  in  probes_heard  list 

Increment  num_epochs_unchanged  by  1; 

if  num_epochs_unchanged==NCLA_MAX_EPOCHS_BETWEEN_RETRANSMISSIONS 

Clear  nodes_that_heard_report; 

Set  nodes_that_miust_be_sent_to  =  EBB; 

State  =  RELAY; 

Update  nodes_that_heard_report ; 

Update  nodes_that_report_must_be_sent_to ; 

Update  last_epoch_for_which_report_was_valid  from  report  received; 

If  nodes_that_must_be_sent_to  is  empty  AND  state  ==  RELAY  Then 
state  =  SAVE 

else 

num_epochs_unchanged=0 ; 

Update  link_qualities  for  reporting  node; 

nodes_that_heard_report=  RB_neighbors  of  transmitting  node; 
nodes_that_report_must_be_sent_to  = 

(EBB_neighbors-RB_neighbors  of  reporting  node) ; 

Update  last_epoch_for_which_report_was_valid  from  report  received; 

If  nodes_that_must_be_sent_to  is  empty  Then 
state  =  SAVE 
else 

state  =  RELAY; 

Figure  23  Pseudocode  for  Procedure  handle_connectivity_repoit  from  node  L 
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//NCLA  uses  the  following  data  structures: 

Use  RB_neighbors  lists  from  PPA; 

Use  probes_heard  list  from  PPA 

Use  LQI  vectors  from  PPA 

Use  EBB_neighbors  list  from  LCA; 

Integer  current_epoch ,  range  (0  to  NCLA_|4AX_EPOCH) ; 

Array  (1 :NUM_NODES)  of  connectivity_control_blocks, 
each  block  contains  the  following: 

State  is  one  of  (UNINITIALIZED. INITIALIZED, SAVE, RELAY, SENT, STALE) 
List  of  nodes_that_heard_report; 

List  of  nodes_that_report_jnust_be_sent_to; 

Integer  epoch_in_which_report_wa8_relayed_by_this_node ; 

Integer  last_epoch_for_which_report_wa8_valid; 

Link  qualities  at  reporting  node; 

Await  occurrence  of  one  of  the  following  events  and  then  process  it: 
CASE  event  is  start  of  epoch: 

Update  current_epoch ; 

FOR  every  report  DO 

if  state  ==  SAVE  OR  state  ==  RELAY  OR  state  ==  SENT  then 
if  current_epoch  ==  laat_epoch_for_which_report_wa8_valid 
then  states  STALE 

CASE  event  is  transmission  opportunity: 

Pack  as  many  reports  as  possible  into  the  NCLA  message, 
that  satisfy  state  ss  RELAY; 

For  each  report  that  is  packed  DO 

epoch_in_which_report_,wa8_re layed_by_this_nodescurrent_epoch ; 
states  SENT; 

CASE  event  is  NCLA  message  received  from  node  t: 

Unpack  connectivity  reports  and  send  them  to  handler; 

Case  event  is  network  reorganized: 

Get  RB_neighbors  and  probes_heard  lists  from  PPA; 

Get  EBB_neighbors  list  from  LCA; 

FOR  all  nodes  in  probes_heard  list 

Create  connectivity  report  from  PPA  database 
Call  handle_connec t ivi ty_repor t ; 

FOR  every  report  DO 

if  state  ss  SAVE  OR  state  ss  RELAY  then 

Recompute  node8_that_report_must_be_sent_to ; 
if  nodes_that_report_must_be_sent_to  list  is  empty  then 
states  SAVE; 
else 

states  RELAY; 

Case  event  is  connectivity  report  received; 

Call  procedure  handle_connectivity_report ; 

Rgure  22  Pfeudocode  for  tbe  NCLA. 
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10.1.4.2  Network  Structuring  (NC_NS)  CSC 


This  CSC  is  responsible  for  developing  a  network  control  structure. 


10.1.4.2.1  Linked  Cluster  Algorithm  (LCA)  CSU 

10.1.4.2.1.1  Linked  Cluster  Algorithm  Design  Specification/Constraints 

The  purpose  of  this  algorithm  is  to  organize  the  network  into  a  Linked  Cluster  structure  [3]. 

10.1.4.2.1.2  Linked  Cluster  Algorithm  Design 

The  LCA  allows  «‘arh  node  to  determine  tte  role  it  should  assume  in  the  cluster  structure  and  to 
learn  who  its  “own”  clusterhead  is.  In  the  version  to  be  used  in  the  NFSE  System,  gateway  nottes  are  not 
selected,  insread,  all  nodes  that  are  cafirtiriar<»s  to  become  gateway  nodes  become  boundary  nodes.  Nodes 
that  are  neither  clusterheads  nor  boundary  nodes  become  terminator  nodes.  The  LCA  also  provides  each 
node  with  a  list  of  RB-ni  ighbors  that  are  also  members  of  the  enhanced  backbone  (EBB)  network  -  these 
are  called  EBB-neighbors.  [3] 

The  LCA  is  piggybacked  onto  the  Periodic  Probing  Algorithm  in  that  it  uses  the  same  set  of 
TDMA  frames  for  communication  and  ii  relies  on  the  bidirectional  connectivity  information  gathered  by 
the  PPA. 

Just  before  its  frame  2  transmission,  each  node  has  obtained  all  the  information  it  needs  to  imple* 
ment  the  first  step  of  the  Linked  Ouster  Algorithm  (that  is,  cluster  formaUon).  It  is  necessary,  however,  to 
include  in  its  frame  2  transmission  an  announcement  of  the  decision  to  become  a  clusterhead,  if  in  fact  the 
node  has  so  decided.  A  node  reveals  this  decision  by  including  the  ID  of  its  v«wn  clusterhead  in  its  frame  2 
transmission.  Each  node  selects  as  its  own  clusterhead  the  lowest  numbered^  clusterhead  to  which  it  is  RB- 
connected.  A  node  decides  to  become  a  clusterhead  if  it  has  not  already  heard  from  a  clusterhead  node  to 
which  it  is  RB-connected. 

At  the  end  of  firame  2,  nodes  determine  if  they  should  assume  the  role  of  boundary  nodes,  and  the 
EBB-neighbors  list  is  derived.  Pseudocode  for  the  LCA  is  shown  in  figures  24, 25,  and  26. 


4.  See  the  sectkn  on  the  PPA  for  a  discussioactfiKxIe  numbering. 
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Use  reliable_2way_connectivity  matrix  (see  PPA) ; 

Wait  for  one  of  the  following  events  and  process  as  indicated: 
Case  start_of_reorganization_epoch: 

ownhead  vector=  (0 . 0 )  : 

nodestatus=UNDEFINED; 

EBB_neighbors  listsempty; 
heads_one_hop_away  list=empty; 
heads_two_hops_away  list=en^ty 
Case  transmit_in_frame2 : 
determine  ownhead  and  store  in  ownhead[i]; 
announce  ownhead [ 1 ] ; 

Case  received_frarie2_transmission_from_node_j : 
ownhead  [  j }  =ownhead  reported  by  node  j 
if  (reliable_2way_connectivity(i, j ] ==1) 

{  if  (ownheadt j ] ==i) 
do  nothing; 

else  if  (reliable_2way_connectivityti, ownhead( j ] ] ==1) 
put  ownhead[j]  into  heads_one_hop_away; 
else 

put  ownhead(j]  into  heads_two_hops_away; 

} 

Case  end_of_frame2 : 
if  (node  i  is  a  CLUSTERHEAD) 

put  any  RB_neighbors  of  self  into  EBB_neighbors ; 
linkupK)  ; 
linkup2  0 ; 

if  (nodestatus  is  not  CLUSTERHEAD  or  BOUNDARY_NODE) 

{  nodestatus=TERMINATOR_NODE; 
put  ownheadd]  into  EBB.neighbors ; 

} 


Figure  24  Pseudocode  for  the  Linked  Cluster  Algorithm  at  Node  i. 


if  (node  i  is  not  a  CLUSTERHEAD) 

{  //it  is  a  candidate  to  be  a  boundary  node 

if  (there  is  at  least  one  pair  of  nodes  in  heads_one_hop_away) 
{  nodes  tatus =BOUNDARY_NODE ; 
put  nodes  in  heads_one_hop_away  into  EBB.neighbors ; 

} 


Figure  2S  Pseudocode  for  procedure  linkupl  at  Node  L 
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if  (node  1  is  not  a  CLUSTERHEAO) 

{  //node  i  is  a  candidate  to  become  a  boundary  node; 

£or  all  pairs  of  clusterheads  (hl=ownhead[i] ,h2) 
where  h2  is  two  hops  from  node  i  do 
{  //check  for  prior  linkage  of  hi  and  h2; 

if  (no  RB_neighbor  of  node  i  is  connected  to  both  h2  and 
one  of  i's  one_hop_away  clusterheads) 

{  nodestatus  =BOUNDARY_NODE ; 
put  hi  into  EBB.neighbors ; 

copy  all  RB_neighbors  whose  ownhead  is  h2  into  EBB_neighbors ; 

} 

) 


Figure  26  Pseudocode  for  procedure  linkup!  at  Node  i. 


10.1.4.3  'transmitter  Control  (XC)  CSC 

The  Transmitter  Control  CSC  is  divided  into  two  component  CSUs  -  a  Transmitter  Control  Driver 
and  the  lYansmission  Scheduling  Algorithm. 

10.1.4.3.1  'Transmitter  Control  Driver  (TCD)  CSU 

10.1.4.3.1.1  Transmitter  Control  Driver  Design  Specification/Constraints 

The  Ttansmitter  Control  Driver  shall  provide  an  interface  for  remotely  setting  the  transmitter  fre* 

quency. 

10.1.43.1.2  Twisniitter  Control  Driver  Design 
TBD 

10.1.4.33  T:*ansniission  Scheduling  Algorittm  (TSA)  CSU 

10.1.4.33.1  'Transmission  Scheduling  Algorithm  Design  Specification/Constraints 

*1116  Transmissioo  Scheduling  Algorithm  shall  cue  the  Transmit  Buffer  Management  CSC  when  it 
is  time  to  schedule  transmissions  by  the  Link  Controller. 

10.1.433.2  Transmission  Sdieduling  Algoridim  Deagn 

A  simpia  Fixed  TDMA  protocol  is  used  to  control  transmissions  in  the  NFSE  System.  The  timing 
for  this  protocol  is  shown  in  figures  7  and  19.  Eadi  node  is  assigned  a  single  slot  during  each  transmission 
frame.  Node  i  is  always  assigned  Slot  i. 
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10.1.4.4  Receiver  Control  (RC)  CSC 

The  Receiver  Control  CSC  contains  one  CSU  -  a  Receiver  Control  Driver. 

10.1.4.4.1  Receiver  Control  Driver  (RCD)  CSU 

10.1.4.4.1.1  Receiver  Control  Driver  Design  Spedfication/Constraints 

The  Receiver  Control  Driver  shall  provide  an  interface  for  remotely  setting  the  receiver  frequency. 

10.1.4.4.1.2  Receiver  Control  Driver  Design 
TBD 

10.1.4.5  ’Dansmit  Buffers  Management  (TBM)  CSC 

The  Transmit  Buffers  Management  CSC  contains  one  CSU  -  the  Transmit  Buffers  Management 
Algorithm  (TBMA)  CSU. 

10.1.4.5.1  Ihuismit  Buffers  Management  Algorithm  (TBMA)  CSU 

10.1.4.5.1.1  Transmit  Buffers  Management  Algorithm  Design  Spedfication/Constraints 

The  TBMA  has  several  functions  -  it  manages  the  storage  of  messages  awaiting  transmission,  it 
packs  messages  into  transmit  buffers,  and  it  generates  and  inserts  sequence  numbers  in  relay  message 
headers.  The  messages  stored  by  the  TBMA  may  originate  in  higher  layers  or  ttey  may  originate  locally  in 
other  NC  algorithms.  For  example,  the  Network  Connectivity  Learning  Algorithm  generates  messages  that 
must  be  transmitted  to  other  NQ.  Also,  it  manages  the  storage  of  pointers  to  messages  that  are  being 
relayed.  Relay  messages  have  their  own  messs^e  store  facility  based  in  the  RBMA  (Receive  Buffers  Man¬ 
agement  Algorithm),  however,  the  TBMA  accesses  relay  messages  via  queues  of  pointers  that  it  maintains. 
The  TBMA  also  handles  the  packing  of  messages  into  the  transmit  buffers  for  transmission  during  the  next 
available  transmission  slot  The  TBMA  packs  the  buffets  based  on  message  lengths,  types,  and  priorities. 
Finally,  the  TBMA  generates  and  inserts  message  sequence  numbers  into  the  headers  of  all  relay-type  n^s- 
sages  originating  at  the  local  NC.  The  reason  to  delay  message  sequencing  to  this  point  is  because  the 
TBMA  determines  the  order  in  which  messages  are  transmitted. 

10.1.4.5.1.2  Transmit  Buffers  Management  Algorithm  Design 

Each  node  has  four  transmit  queues,  tiK  Send_local  (^ueue,  the  Setxi_global  Queue,  the  Broadcas- 
t.relay  (^eue,  and  the  Point_to_point_reIay  (^leue.  The  Sendjocal  Queue  contains  messages  originating 
at  this  tKxle  and  being  sent  to  nodes  no  farther  than  one  hop  away,  i.e.,  no  relaying  required,  and  die  Send_- 
global  Queue  contains  messages  originating  at  this  node  and  being  sent  to  nodes  diat  may  be  farther  dian 
one  hop  away,  i.e.,  relaying  may  be  required.  The  two  remaining  queues  -  Broadcast.relay  and  Point_- 
to_poii!t_relay  -  do  not  contain  the  actual  relay  messages.  Rather,  they  contain  message.tap  diat  have  the 
following  attributes:  1)  (an  index  that  locates  the  relay  message  in  the  RBMA’s  Message 

Sum),  2)  message.type,  3)  prir^ty,  4)  length,  and  5)  time.in  (the  time  the  message  was  received  by  this 
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NC).  In  each  queue,  messages  (or  message.tags)  are  ordered  by  priority  with  the  highest  priority  message 
at  the  head  of  the  queue. 


When  a  transmission  slot  opportunity  arises,  the  Transmission  Buffer  Management  Algorithm  tries 
to  fill  the  transmit  packet  buffer.  The  sequence  of  events  that  follows  is  described  in  the  TBMA  pseudo 
code  (Figure  27).  The  fixed  TDM  A  slots  of  Frames  1. 2.  and  3  begin  with  synchronous  data  derived  by  NC 
algorithms  (PPA,  LCA,  TS  A.  and  CCA)  with  their  remainders  packed  with  asynchronous  messages  from 
the  four  transmit  queues.  All  other  slots  contain  only  asynchronous  messages.  The  first  asynchronous  mes¬ 
sage  put  into  the  packet  is  the  highest  priority  message.  If  there  is  room  for  additional  messages,  the 
TBMA  looks  for  die  next  highest  priority  message  that  will  fit  into  the  remainder  of  the  packet  and  puts  it 
into  the  slot  The  process  repeats  until  there  are  no  more  messages  that  can  fit  into  the  packet  buffer.  It  is 
possible  that,  at  times,  the  TBMA  will  not  be  allowed  to  accept  traffic  from  the  Send_global  queue.  The 
Congestion  Control  Algwithm  may  effect  this  blockr^e  to  prevent  traffic  congestion  in  the  network  or 
RBMA’s  limit  on  the  number  of  messages  that  can  be  injected  to  prevent  duplication  of  message  sequence 
numbers  may  effect  the  blockage. 

10.1.4.6  Receive  Buffers  Management  (RBM)  CSC 

The  Receive  Buffers  Management  CSC  contauns  one  CSU  -  the  Receive  Buffers  Management 
Algorithm  (RBMA)CSU. 

10.1.4.6.1  Receive  Buffers  Management  Algorithm  <RBMA)  CSU 

10.1.4.6.1.1  Receive  Buffers  Management  Algorithm  Design  Specification/Constraints 

The  Receive  Buffers  Management  Algorithm  checks  each  block  of  an  incoming  packet  for  block 
errors^,  unpacks  messages  from  each  receiver’s  Receive  Buffer,  and  forwards  each  message  to  the  aiq>ro- 
priate  destination  within  the  NC.  The  RBMA,  also,  prevents  duplicate  messages  from  being  delivered  to 
the  upper  layer  and  removes  relay  messages  from  relay  queues  (i.e.,  from  the  RBMA  message  store)  that 
have  exceeded  their  time-to-live. 

10.1.4.6.1.2  Receive  Buffers  Management  Algorithm  Design 

When  a  packet  is  received  at  the  receive  buffer,  it  has  the  same  block  format  shown  in  figure  58  — 
minus  the  checksum  bytes.  It  is  unpacked  block  by  block  message  by  message,  and  it  is  checked  for  errors. 
Starting  at  the  front  of  the  receive  buffer,  the  RBMA  parses  the  receive  buffer  searching  for  messages.  Any 
synchronous,  control  messages  are  located  at  the  start  of  a  buffer,  and  their  lengths  are  known.  The  header 
of  the  first  asynchronous  message  comes  immediately  after  any  synchronous  messages,  and  therefore  the 
location  of  this  header  is  also  known.  The  header  contains  information  on  the  length  of  the  message.  Thus, 
the  header  of  the  first  asynchronous  message  must  be  received  correctly  in  order  to  determine  where  the 
next  message  header  occurs.  Thus,  if  the  RBMA  discovers  an  error  in  a  block  that  contains  a  message 
header,  all  the  remaining  blocks  in  the  packet  must  also  be  discarded.  This  is  because  each  message  header 
contains  a  message  length  indicator.  Without  the  message  length  indicator  it  is  inqtossible  to  tell  where  the 
current  message  ends  a^  the  following  message  in  the  packet  begins.  In  fact,  none  of  the  remaining  mes- 


5.  Error  syndromes  are  computed  by  the  Link  Controller  and  sent  to  the  Network  ControilCT  for  use  in  determining 
message  errors  and  link  quality. 
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Confute  pkt_pos  //  the  position  of  the  first  available  bit  in  the  packet 
//  where  packing  of  asynchronous  messages  may  begin 
//Fill  the  remainder  of  the  buffer  with  asynchronous  messages 
if  cluster  schedules  are  installed  then 
while  room  for  more  messages  do 

find  the  highest  priority  level  max_pri  of  messages  in  the  send_local, 
send  global,  broadcast.relay,  and  point_to_point_relay  queues; 
find  the  maximum  length  max_len  of  new  traffic  permitted; 
if  RBMA  limit  on  number  of  new  messages  is  exceeded  then 
meuc_len  =  0; 

Request  data  from  NTDS  Port  with  priority  >  max_pri 
and  length  <  iMUc_len; 

Pack  the  NTDS  message,  if  there  is  one; 

insert  source.id  and  sequence_number  into  ntds_pkt  header ; 
confute  pkt_pos,  pkt_remainder.  and  traf f ic_limit; 
case  send  global  q  has  msg  and  traf fic_limit>=msg. length 
and  pkt_remainder>=msg. length  and  msg.priority==max_pri : 

//Send  a  global  msg  (broadcast  or  pt2pt)  sourced  at  this  node 
insert  source_id  and  sequence_number  into  msg  header; 
remove  msg  from  send  global  q; 
write  msg  into  transmit  buffer; 

compute  pkt_pos,  pkt_remainder  and  traf f ic_limit; 
case  broadcast_relay_q  has  msg  and 

broadcast_relay_q. priority  >«  pt2pt_relay_q. priority 
and  broadea8t_relay_q. priority  >*  send_local_q. priority 
and  pkt_remainder  >*  msg. length: 

//Send  a  broadcast  message  relayed  by  this  node 
remove  msg  from  broadcast_relay_q; 
write  msg  into  transmit  buffer; 
call  BTRA.msg_sent; 
compute  pkt_pos,  and  pkt_remainder ; 
case  pt2pt_relay_q  has  msg  and 

pt2pt_relay_q. priority  >=  send_local_q. priority 
and  pkt_remainder  >=  msg. length: 

//Send  a  pt2pt  message  relayed  by  this  node 
remove  msg  from  pt2pt„relay_q; 
write  msg  into  transmit  buffer; 
compute  pkt_pos,  and  pkt_remainder ; 
case  send_local_q  has  msg  and  pkt_remainder  >=  msg. length: 

//Send  a  local  msg 
remove  msg  from  8end_local_q; 
write  msg  into  transmit  buffer; 
compute  pkt_pos,  and  pkt_remainder; 
case  all  other  cases: 

//Send  a  null  message 

write  null  msg  into  transmit  buffer; 

pkt_remainder  =  0; 


Figure  27  Pwudocode  for  the  TBMA. 
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sages  in  the  packet  may  be  unpacked  even  if  the  remaining  blocks  are  correct  once  synchronization  with 
the  message  headers  is  lost. 

When  a  packet’s  constituent  messages  are  unpacked,  they  are  routed  internally  to  processes  and 
queues  within  the  NC  based  on  the  address  given  by  the  nc_pott  held  in  the  message  header.  The  pseudo 
code  shown  in  Figure  28  and  Figure  29  give  the  details  of  RBMA  operation. 

The  synchronous  data  in  hie  hxed-TDMA  slots  of  frames  1. 2,  and  3  are  handled  hrst.  then  the 
asynchronous  messages  are  unpacked.  End*of*data  (i.e..  Null)  and  Local  messages  canimt  be  relayed  nor 
do  they  possess  a  Message  Identiher  (MID).  Each  point-to-point  and  broadcast  messs^e  has  a  MID  that  is 
used  for  duplicate  message  detection  and  removal.  The  Message  Identiher  consists  of  the  Source  Address 
(address  of  the  node  that  originated  the  message  -  NB_NODE_ID  bits)  and  a  Sequence  Number  •  NB.SEQ 
bits. 


The  hfst  step  (see  Figure  29)  in  processing  hie  incoming  stream  of  asynchronous  message  bits  is  to 
determine  if  more  asynchronous  messages  can  be  unpacked.  If  fewer  than  two  bits  remain  to  be  processed 
or  if  the  next  message  is  a  Null  message,  then  processing  is  hnished  because  all  messages  have  been  pro¬ 
cessed.  If  messages  remain  to  be  processed,  the  length  held  of  the  next  message  is  checked  for  errors.  If  it 
is  error  hee,  processing  may  continue:  otherwise,  processing  must  be  terminated.  If  processing  continues, 
the  remainder  of  the  message  header  and  the  messt^e  data  held  are  checked  for  errors  and.  if  all  is  well,  the 
messi^e  is  processed. 

Local  messages  are  merely  routed  to  the  internal  NC  process  designated  by  the  nc_port  held  of  the 
message.  However,  if  the  message  is  a  point-to-point  or  a  broadcast  message,  RBMA  must  determine  if  the 
message  is  new  or  old.  The  algorithm  makes  this  determination  by  using  a  MAX_NET_SIZE  *  MAX_- 
SEQ  *  I  bit  matrix  and  a  queue  that  holds  MSG_STORE_SZ  MlDs.  The  bit  matrix  is  initialized  to  zeros. 
When  a  message  is  receiv^,  its  Source  Address  and  Sequence  Number  are  used  as  matrix  indices  to  inter¬ 
rogate  a  single  bit.  If  the  bit  is  set  to  0,  the  message  is  declared  to  be  a  new  message,  the  bit  is  set  to  1 ,  and 
the  message’s  MID  is  put  into  the  queue.  On  the  other  hand,  if  the  interrogated  bit  is  set  to  a  1,  the  message 
is  declared  to  be  old.  When  an  old  MID  pops  out  of  the  queue  •  which  is  a  result  of  putting  a  new  MID  into 
a  full  queue  -  the  MID  is  again  used  to  select  a  bit  in  the  matrix,  only  this  time  the  bit  is  reset  to  0. 

New  broadcast  and  point-to-point  messages  are  put  into  the  RBMA  message  store  facility  using  a 
message  store  index  computed  by  incrementing  an  index  counter.  Also,  a  message  tag  is  aeated  for  each 
new  message,  which  contains  the  index,  the  message  type,  message  priority,  message  length,  and  a  time 
stamp  indicating  when  the  message  was  received  by  the  RBMA.  The  BTRA  or  P2PRA,  depending  on  the 
message  type,  is  then  notified  that  the  message  has  arrived.  At  die  destination  of  a  message,  a  copy  of  the 
message  is  delivered  to  the  NC  process  designated  by  the  NC  port  held. 

The  RBMA  also  implements  a  procedure  to  purge  old  messages  in  order  to  insure  diat  a  node 
never  sees  two  different  messages  with  the  same  MID  at  the  same  time.  Our  solution  to  this  problem  is  to 
give  each  message  a  predetermined  time-to-live  at  a  relay  node;  call  it  ti.  Since  the  messt^e  tag,  created 
when  a  message  is  unpacked  from  the  receive  buffer,  contains  the  time  that  a  messr^e  was  received  by 
RBMA,  a  background  process  running  in  RBMA  can  periodically  cull  the  message  store  for  messages 
exceeding  their  time-to-live  at  this  node.  If  t^  is  the  time  it  takes  to  cycle  through  all  of  the  sequence  num¬ 
bers  at  a  node,  then  to  prevem  an  old  message  from  ever  having  the  same  sequence  number  as  a  new  one, 
it  is  necessary  that  1),  where  W  is  die  number  of  nodes  in  the  network.  It  is  a  function  of  die 

traffic  throttling  procedure  of  RBMA  to  insure  that  this  condition  is  always  satisfied,  given  N  and  q.  Thus, 
the  maximum  average  rate  at  which  new  messages  can  be  generated  is  n,/(r^(N- 1))  ufiiete  n,  is  the 
maximum  sequence  number. 
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case  timing  event  for  reading  data  from  ftdma  receive  buffer: 

//RBMA  pseudo  code  for  unpacking  the  ftdma  buffer 
update  link  quality  information; 
if  the  ftdma  receive  buffer  holds  a  packet  then 
determine  frame_num  from  CAA; 
determine  sender  from  RSA; 

//unp>ack  frames  1,  2,  &  3  synchronous  messages 
case  frame_num  =  1: 
unpack  frame  1; 

call  PPA,  CAA,  &  CCA  with  sender  &  sync_msg; 
case  f rame_num  =  2 : 
unpack  frame  2; 

call  PPA,  LCA,  &  CAA  with  sender  &  sync_msg; 
case  frame_num  =  3 : 
unpack  f reime  3 ; 

call  CAA  with  sender  Sc  sync_msg; 
unpack  asynchronous  messages: 
case  received  packet  from  receiver: 
set  holds_pkt  to  true; 

Figure  28  Outer  block  pseudocode  for  RBMA 

10.1.4.7  Congestion  Control  (CC)  CSC 

The  Congestion  Control  CSC  contains  one  CSU  -  the  Congestion  Control  Algcnitlun  (CCA)  CSU. 

10.1.4.7.1  Congestion  Control  Algorithm  (CCA)  CSU 

10.1.4.7.1.1  Congestion  Control  Algorithm  Design  Spediication/Constraints 

The  function  of  the  Congestion  Control  Algorithm  is  to  prevent  the  degradation  of  network  perfor¬ 
mance  that  can  occur  when  traffic  levels  exceed  that  which  the  network  can  effectively  handle. 

10.1.4.7.1.2  Congestion  Control  Algorithm  Design 

The  Congestion  Control  Algorithm  tries  to  maintain,  globally,  a  maximum  rate,  g,  at  which  new, 
network  traffic  can  be  transmitted  by  a  node.  New,  network  traffic  is  defined  here  to  mean  traffic  that  has 
not  been  previously  transmitted  and  which  the  network  is  expected  to  route  to  its  destination.  Network  traf¬ 
fic  is  distinguished  fi’om  local  traffic,  which  the  network  does  not  have  to  relay.  This  net-wide  limitation  on 
new,  network  traffic  is  shared  by  all  nodes.  That  is,  the  limitation  is  based  on  a  fictitious  uniform  loading  of 
the  network.  From  the  computed  rate  g  and  the  traffic  loading  at  node  i,  node  i  is  able  to  determine  the 
maximum  rate  g^  at  which  it  can  transmit  new  network  traffic.  The  rates  g  and  gi  are  measured  in  units  of 
MAX_USER_DATA  bits  of  information  per  FTDMA  frame. 

The  interin^etation  of  the  traffic  limit  is  as  follows.  Suppose  the  traffic  limit  g,  is  0.3.  This  means 
that  every  FTDMA  schedule  period  node  i  can  transmit,  with  probability  0.3,  MAX_USER_DATA  bits  of 
new  networic  traffic.  Whether  node  i  is  allowed  to  transmit  this  additional  new,  network  data,  is  determined 
by  making  a  random  draw  firom  a  uniform  distribution  ova  the  range  0  to  1.0  at  the  beginning  of  every 
FTDMA  frame.  If  the  result  of  this  draw  is  a  numba  that  is  less  than  the  fractional  slot  traffic  limit  (0.3  in 
this  examine),  then  tiie  node  is  allowed  to  transmit  MAX_USER_DATA  bits  of  information  during  that 
fiame. 
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//unpack  asynchronous  messages 
while  more  messages  in  buffer  do 

if  less  than  2  bits  remain  in  buffer  then 
more_messages  is  false 
else 

if  message  type  field  ok  then 
get  message  type; 
if  message  type  is  NULL  then 
more_messages  is  false 
else 

if  message  length  field  not  ok  then 
more_messages  is  false 
else 

get  message  length; 
if  message  header  field  ok  then 
get  nc  port; 

if  message  data  field  ok  then 
msg_ok  is  true; 
get  reliability; 

if  msg_ok  or  reliability  is  false  then 
case  message  type  is  LOCAL: 

send  message  to  nc  port; 
case  message  type  is  BROADCAST: 
get  message  priority; 
get  message  source; 
get  message  sequence  number; 
if  message  source  <>  this  node  then 
if  message  is  not  old  then 

put  message  into  message  store; 
call  BTRA.received_message; 
send  message  to  nc  port; 
else 

send  call  BTRA.received_message; 
case  message  type  is  PT2PT; 
get  message  priority; 
get  message  source; 
get  message  sequence  number; 
get  message  destination; 
if  message  source  <>  this  node  then 
if  message  is  not  old  then 

put  message  into  message  store; 
call  P2PRA.received_message; 
if  message  destination  =-  this  node  then 
send  message  to  nc  port; 


Figure  29  Pseudo  code  for  RBMA  asynchronous  message  handling 
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The  value  of  g  is  computed  as  follows.  To  allow  varying  the  rate  g,  the  Congestion  Control  Algo¬ 
rithm  maintains  two  values  for  g.  namely,  a  new  value  £„  and  an  old  value  g^.  At  network  startup  gp  is  ini¬ 
tialized  to  CCA_INIT_GLOBAL_FACTOR.  Thereafter,  at  the  start  of  every 
CCA_EP0CHS_BETWEEN_INITS  epochs,  the  Congestion  Control  Algorithm  first  sets  go  =  gn 
resets  gn  to  CCA_MAX_GLOBAL_FACTOR.  The  CCA  uses  the  following  method  to  update  gn  between 
these  initializations.  During  frame  1  of  each  reorgaiuzation  epoch  each  node  i  announces  a  measure.  Bp  of 
the  network  traffic  backlog  at  that  node.  Let  the  corresponding  traffic  load  (in  bits)  be  given  by  L.  An  esti¬ 
mate  of  the  current  value  of  L  at  a  node  is  obtained  from 


4y-9,  +  T.  if  (9^- +  r>  0) 

^  "  ^MAX_USER_DATA,  if  (qf-q.-^TiO) 


(EQ14) 


where  q  is  the  size  of  the  network  traffic  backlog  at  the  node,  and  the  subscripts  f  and  i  refer  to  the 
final  and  initial  values  of  q  during  the  previous  measurement  epoch.  T  is  the  number  of  bits  transmitted  as 
network  traffic  during  that  same  measurement  period. 


Let  C  stand  for  the  available  transmission  capacity  per  epoch  at  the  node,  where  each  slot  is  pre¬ 
sumed  to  represent  MAX_USER_DATA  bits  of  transmission  capacity.^  Thus,  in  the  case  of  FTDMA,  the 
available  transmission  capacity  at  each  node  is  fixed  at 

C  =  M AX_USER_DATA  *  NUM  .FRAMES_PER_EP(X:H  (EQ  1 5) 


If  L  <  C,  that  is,  if  there  is  excess  capacity,  there  is  the  possibility  that  transmission  queues  at  the 
node  can  be  reduced  and,  under  certain  concUtions,  the  net-wide,  maximum  allowed  traffic  loading  on  the 
network  may  be  increased.The  expected  reduction  in  transmission  queue  size  for  the  upcoming  transmis¬ 
sion  epoch,  qc.  is  computed  using  (EQ  16). 


0, 

C-L, 


if(C-L<0) 
dffiiC-L’iqj) 
if  («^<  C-L) 


Each  node  can  compute  a  scale  S,  which  is  defined  as  follows. 


S  =  (C-qc)/L. 


(EQ16) 


(EQ17) 


We  define  excess  capacity  x^.  as  follows. 

(C-l-q^),  if{C-L-q^>0) 

0.  if(C-L-q^<0) 

Likewise,  we  define  an  excess  scale  Sx  as 

^x  ~ 


(EQ18) 


(EQ19) 


from  the  scales  S  and  Sx  each  node  computes,  at  the  end  of  frame  1 ,  a  local  value  1  for  the  maxi¬ 
mum  allowed  traffic  rate.  At  the  outset  of  this  computation  1  is  set  equal  to  g^.  One  of  three  formulas  is 
used  depending  on  the  values  of  S  and  Sj.  If  S  is  less  than  SWITCH,  we  use 


6.  Actually,  each  slot  can  bold  slightly  more  than  MAX_USER_DATA  bits  of  information.  A  more  accurate  estimate 
of  C  would  take  into  account  the  amount  of  synchronous  message  traffic  sent  in  each  slot 
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1  =  go  (S/SWITCH)2.  if  S  <  SWITCH 


(EQ20) 


otherwise 

1  =  go+  RAMP  (Sx  -  RAMP),  if  RAMP  <  Sx  <  RAMP  +  1  (EQ  21) 


or 


l  =  go  +  RAMP,ifSx>RAMP+ 1  (EQ22) 

If  I  <  £„,  the  node  sets  the  new  global  rate  g„  to  1. 

Just  prior  to  its  own  frame  2  transmission,  each  clusterhead  does  similar  computations  of  1  for 
itself  and  eac^  of  its  RB-neighbors.  It  then  sets  lQ,i„  =  minimum  1  for  all  of  these  nodes.  If  I^un  <  gn  then  the 
clusterhead  sets  gn  =  Innn.  Between  initializations  every  CCA_EPOCHS_BETWEEN_INrrS  epochs  the 
new  value  of  gp  is  sent  to  all  nodes  by  the  CCA  using  asynchronous,  local  messages.  The  format  of  these 
messages  is  shown  in  Figure  30.  The  method  used  to  send  these  messages  to  all  nodes  is  similar  to  that 
used  to  send  broadcast  messages  using  the  Broadcast  Traffic  Routing  Algorithm.  When  such  a  message  is 
received  by  a  node,  the  local  g„  is  undated  to  the  value  in  the  message  -  provided  that  value  is  less  than  the 
local  value  of  gn-  Details  of  the  protocol  for  processing  incoming  Congestion  Control  Messages  are  given 
in  Figure  32. 


Description  of  Field  bits 


a.  Global  Congestion  Factor  NB_CLB_CONGES!TION_FACTOR 


Data  packet  size  (bits)  NB_GLB_CONGESTION_FACTOR 

Figure  30  Format  of  a  Congestion  Control  data  packet  containing  an  updated  value  for  the  global  congestion  control  factor. 


Non-uniform,  new  traffic  loading  is  handled  as  follows.  During  frame  1  of  each  reorganization 
epoch,  each  node  i  announces  an  integer  Ri,  which  is  the  amount  of  new.  global  traffic  awaiting  transmis¬ 
sion.  At  the  end  of  frame  2  each  node  computes  a  new  maximum  rate  gj  for  entering  new  traffic  into  the 
network. 


«.=  (EQ23) 

j 

where  AT  is  1  plus  the  number  of  reliable  bidirectional  neighbors  of  node  i,  and  the  summation 
extends  over  node  i  and  all  of  its  bidirectional  neighbors. 

Pseudocode  for  the  Congestion  Control  Algorithm  is  given  in  Figure  31  and  Figure  32. 
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//Data  Structures  used  by  CCA 
Use  RB_neighbors  lists  from  PPA; 

Use  EBB_neighbors  list  from  LCA; 
float  global_factor_step_size; 
float  go; 

enum  local_bc_msg_cntrl_blk_state 

{UNINITIALIZED, INITIALIZED, SAVE, RELAY, SENT, STALE} ; 
struct  cca_msg_control_block  { 
int  gn; 

List  nodes_that_heard_report ; 

List  nodes_that_repor t_must_be_sent_to ; 
local_bc_msg_cntrl_blk_state  state,*}  cblk; 

Await  occurrence  of  one  of  the  following  events, 
then  process  as  indicated  below: 
case  startup: 

cblk . gn=CAA_INIT_GLOBAL_FACTOR ; 

cblk . nodes_that_report_muat_be_sent_to=EMPTY ; 

cblk.state=INITIALIZED; 

global_factor_step_size= 

CCA_MAX_GLOBAL_FACTOR/  (2NB-GlB_CONGEsnON.FACroR  _  jj 
case  start_of_an_initialization_epoch: 
go=cblk.gn*global_factor_step_size; 
cblk . gn=CAA_INlT_GLOBAL_FACTOR ; 
cblk.state=INITIALIZED; 
tbma->set_traf f ic_limit (go) ; 

Case  start_of_own_freuiie2_slot: 
if  (s  is  a  CLUSTERHEAD)  { 

confute  1  for  self  and  all  RB  neighbors; 

Iminsmin  of  this  set  of  1;} 
else  { 

compute  1  for  self; 

Iminsl;} 

if  (lmin<cblk.gn) 
cblk.gn=lmin; 

cblk . nodes_that_heard_msg=EMPTY ; 

cblk . nodes_that_report_must_be_sent_to=EBB_neighbors ; 
cblk . statesRELAY; 
case  received_cca_msg  from  node  t 
handle_cca_insg (t.rcvd  an)  ; 
case  network  reorganized: 

Get  RB_neighbors  of  neighbor  nodes  from  PPA; 

Get  EBB.neighbors  list  from  LCA; 

if  (cblk. state  ==  SAVE  OR  cblk. state  ==  RELAY)  { 

Reconpute  olbk . nodes_that_report_jmist_be_sent_to ; 
if  (cblk.node8_that_report_inust_be_sent_to  list  is  entity) 
cblk. state  =  SAVE; 
else 

cblk. state  =  RELAY;} 
case  transmission_opportunity: 
if  (cblk.8tate»=RELAY)  { 

send  cblk.gn  in  a  local  message; 
cblk. state  s  SENT;} 

Figure  31  Pseudocode  for  the  CCA  St  node  I. 


procedure  handle_cca_msg ( int  t,  int  rcvd_gn) 

//  t  is  the  id  of  transmitting  node 

{ 

if  (rcvd_gngn  >  cblk.gn) 

;  //Ignore  the  cca  message  just  received; 
else  if  rcvd_gngn  ==  cblk.gn)  { 
if  (cblk. state! =sent)  { 

Update  cblk.nodes_that_heard_msg; 

Update  cblk . nodes_that_must_be_sent_to ; 
if  (cblk.nodes_that_must_be_s6nt_to  is  enpty  AND 
(cblk. state  ==  RELAY  OR  cblk. state  ==INITIALIZED) ) 
cblk . states  SAVE ; } 
else  {//gn  <  cblk.gn 

Clear  cblk . nodes_that_heard_rasg ; 
cblk.nodes_that_must_be_sent_to  =  EBB  neighbors; 
cblk. state  =  RELAY; 

Update  cblk . nodes_that_heard_msg ; 

Update  cblk . nodes_that_report_must_be_sent_to ; 

If  {cblk.nodes_that_must_be_sent_to  is  empty) 
cblk. state=SAVE} 


Fio  32  Pseudocode  for  Procedure  bandle_cca_report 

10.1.4.8  Message  Router  (MR)  CSC 

10.1.4.8.1  Broadcast  Traffic  Routing  Algorithm  (BTRA)  CSU 

10.1.4.8.1.1  Broadcast  IVaffic  Routing  Algorithm  Design  Spedfication/Constraints 

The  function  of  the  Broadcast  ThUhc  Routing  Algorithm  is  to  send  a  broadcast  message  to  all 
nodes  in  a  network  that  is  organized  into  Linked  Clusters. 

10.1.4.8.1.2  Broadcast  Traffic  Routing  Algorithm  Design 

Each  node  follows  the  same  rule  to  determine  whether  it  should  relay  a  broadcast  message.  The 
rule  is  to  transmit  the  message  if  any  EBB  neighbors  have  not  received  the  message  already.  But  how  do 
we  determine  when  a  neighbor  has  received  a  message?  The  HF  Controller  assumes  that  the  RB  neighbors 
of  a  transmitting  node  all  receive  that  transmission.  Consequently,  for  each  broadcast  message,  a  node 
maintaias  two  lists.  One  list  identifies  to  which  nodes  a  message  still  needs  to  be  sent  •  this  list  is  initialized 
to  a  no^'s  current  EBB  neighbors  when  the  message  is  first  received,  and  reinitialized  after  every  reorga¬ 
nization.  The  second  list  identifies  the  nodes  that  are  assumed  to  have  already  received  the  message  -  this 
list  is  updated  every  time  the  message  is  received.  If  drere  are  any  iKxIes  on  the  first  list  when  a  transmis¬ 
sion  opportunity  arises,  then  that  message  will  be  transmitted.  Hgure  33  contains  pseudocode  that 
describes  the  operation  of  die  BTRA  in  more  detail. 
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//BTRA  uses  the  following  data  structures; 

Use  RB_neighbors  list  from  PPA  -  add  self  to  this  list; 

Use  EBB_neighbors  list  from  LCA; 

Array  (0:MAX_SEQ)  of  Structure  message_control_block 
List  of  nodes_that_heard_message ; 

List  of  nodes_that jnessage_must_be_sent_to; 

Flag  indicating  whether  message  is^to_be_transmitted; 

Await  occurrence  of  one  of  the  following  events  and  then  process  it 
Case  event  is  network_reorganlzed: 

Get  RB_neighbors  list  from  PPA  and  add  self  to  this  list; 

Get  EBB_neighbors  list  from  LCA; 

For  all  none-empty  message_control_blocks  do 
Reconpute  nodes_that_message_must_be_sent_to ; 

Update  is_to_be_transmitted  flag  based  on  results  of  previous 
line; 

If  is_to_be_transmitted  flag  changes  then 
notify  TBMA; 

Case  event  is  broadcast_message_sent : 

Release  message_control_block; 

Case  event  is  message_deleted_from_local_archive: 

Release  message_control_block; 

Case  event  is  broadcast_message_receiv6d_over_the_air : 

If  message  is  a  duplicate  Then 

If  message_control_block  is  empty  Then 
done  processing  event; 

Else  when  message_control_block  is  not  empty  Do 
Update  nodes_that_heardjmessage; 

Update  nodes_tha t_mus  t_be_sent^to ; 

If  nodes_that_must_be_sent_to  is  enpty  Then 
If  message  is  flagged  to  be  sent  Then 
Flag  it  not  to  be  sent; 

Notify  TBMA  that  message  is  not  to  be  sent; 

Else  when  still  need  to  send  message  to  some  nodes  do 
If  message  is  not  flagged  to  be  sent  Then 
Flag  it  to  be  sent: 

Notify  TBMA  that  message  is  to  be  sent; 

Else  when  message  is  not  a  duplicate  do 

Create  and  initialize  a  new  message_control_block; 

If  nodes_that_inust_be_sent_to  is  enspty  Then 
Flag  message  as  not  to  be  sent; 

Else  when  still  need  to  send  message  to  some  nodes  Do 
Flag  message  as  to  be  sent; 

Notify  TBMA  to  send  message: 

Rgure  33  pMudocode  for  the  Broadcast  Traffic  Routing  Algorithm. 
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10.1.4.8^  Point-to- Point  Routing  Algorithm  (P2PRA)  CSU 


10.1.4.8.2.1  Point>to<Point  Routing  Algorithm  Design  Specification/Constraints 

The  purpose  of  this  algorithm  is  to  compute  the  next  relay  node  for  point-to-point  messages. 

10.1.4.8JI.2  Point'to-Point  Routing  Algorithm  Design 

The  point-to-point  routing  function  is  comprised  of  four  important  components.  The  first  is  the 
metric,  which  specifies  the  criterion  for  choosing  a  path.  Next  is  the  measurement  process,  which  enables 
continuous  monitoring  of  the  network  parameters  needed  for  optimizing  routes.  The  third  is  the  updating 
protocol,  which  governs  the  dissemination  of  the  measurements  through  the  network.  Last  is  the  routing 
algorithm,  which  calculates  the  “best”  route  on  the  basis  of  the  metric  and  the  parameter  measurements.In 
the  sections  covering  the  Transmit  Buffer  Management  and  Receive  Buffer  Management  Algorithms  we 
describe  the  measurement  process  used  to  determine  the  Link  Quality  Indexes,  which  are  the  measure¬ 
ments  on  which  the  P2PRA  depends.  In  the  sections  ojvering  the  Periodic  Probing  and  Network  Connec¬ 
tivity  Learning  Algorithms  we  describe  the  protocols  for  disseminating  these  measurements  to  all  nodes  in 
the  network.  In  this  section  we  describe  the  routing  metric  and  the  routing  algorithm. 

It  is  typical  for  routing  metrics  to  be  based  on  throughput  and  delay.  Minimum-hops  routing  is 
generally  used  in  place  of  maximum  tliroughput  routing  because  it  is  much  simpler  to  implement  and 
approximates  maximum  throughput.  However,  ntinimum-hop  routing  treats  links  as  either  present  or 
absent,  when,  in  fact,  link  quality  may  vary  over  a  wide  range.  Thus,  for  example,  it  may  be  preferable  to 
route  traffic  over  a  highly  reliable  two-hop  path  instead  of  over  an  unreliable  one-hop  path.  The  Point-to- 
Point  Routing  Algorithm  routes  traffic  ba^  both  on  the  number  of  hops  required  and  path  reliability.  The 
P2PRA  seeks  paths  that  minimize  the  following  metric. 

i/(n*(LQij./LQi™,))  (EQ24) 

The  product  is  over  all  links  along  the  path,  and  the  hop  factor  h  is  a  number  less  than  1 .  The  hop 
factor  is  included  to  bias  the  metric  in  favor  of  paths  with  fewer  hops.  The  Link  Quality  Indexes,  provided 
by  the  PPA  and  NCLA,  are  used  to  determine  path  relisrt>ility. 

The  routing  algorithm  that  is  used  is  Dijkstra’s  shortest  path  algorithm.[10]. 

10.1.4.9  Network  Manager  (NM)  CSC 

10.1.4.9.1  Network  Status  Monitoring  Algorithm  (NSMA)  CSC 

The  Network  Status  Monitoring  Algorithm  manages  the  local  performance  database.  NSMA  is 
responsible  for  archiving  performance,  and  it  is  intended  to  serve  as  an  external  interface  for  purposes  of 
monitoring  and  controlling  the  operation  of  the  network. 
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10.1.4.9.1.1  Network  Status  Monitoring  Algorithm  Design  Spedfication/Constraints 

10.1.4.9.1.2  Network  Status  Monitoring  Algorithm  Derign 

Several  CSUs  of  the  Network  Controller  periodically  send  to  the  NSMA  a  status  report  Each 
report  contains  data  that  characterizes  the  performance  of  that  CSU.  Some  of  this  data  may  be  archived  for 
post  analysis  of  network  operation  and  some  may  be  displayed  at  the  System  Operator's  console.  The  fol¬ 
lowing  paragn^)hs  summarize  the  contents  of  each  of  these  reports.  The  paragr^  header  contains  tte 
name  of  the  report  and,  in  parentheses,  when  the  report  is  sent  to  the  NSMA. 

•  PPA  Report  (Sent  in  slot  1  of  frame  3  of  each  epoch) 

RB_neighbors  of  this  node; 

LQIs  for  all  incoming  links  at  this  node; 

Frame  1  probes  heard  by  this  node; 

•  LCA  Report  (Sent  in  slot  1  of  frame  3  of  each  epoch) 

Clusteiheads  one  hop  away; 

Clusterheads  two  hops  away  ; 

EBB  neighbors  of  this  node; 

Node  status  (i.e.,  clusterhead,  boundary,  or  terminamr  node); 

Own  clusteihead’s  ID; 

•  CAA  Report  (Sent  in  slot  1  of  frame  3  of  each  epoch)  (UNT  only) 

#  number  of  cluster  schedules  in  report; 

#  cluster  schedules  in  effea  at  this  node; 

The  following  arrays  range  from  1  to  CAA_MAX_NUM_CL_SCHEDS_REPORTED: 
array  of  schedule  creator  IDs; 
array  of  schedule  sizes; 
array  of  transmission  schedules; 
array  of  slot  allocations; 

•  RSA  Report  (Sent  in  slot  1  of  frame  1  of  each  epoch)  (UNT  only) 

Receiver  utilization  statistics 

#  slots  with  insufficient  number  of  receivers 

•  CCA  Report  (Sent  in  slot  1  of  frame  3  of  each  epoch) 

Array  of  traffic  limits  requested; 

#  bits  of  new-fraffic  sent; 

#  bits  new-traffic  allowed; 

•  NCLA  Report  (Sent  in  slot  1  of  frame  3  of  eadi  epoch) 

Link  qualities  vectors;  (other  nodes  only) 

Vector  of  most  recent  update  times  for  LQIs 

•  TBMA  Report  (Sent  in  slot  1  of  frame  1  of  eadi  epoch) 

Statistics  on  messages  sent; 

Statistics  on  message  buffer  utilization; 

Statistics  on  slot  utilization; 

•  RBMA  Report  (Sent  in  slot  1  of  frame  1  of  each  epoch) 

Statistics  on  messages  received; 

Statistics  on  receive  buffer  utilization; 
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St^stics  on  block  errors: 

Log  of  block  errcM-s; 

Log  of  g^bieu  messages; 

•  BTRA  Report  (Sent  in  slot  1  of  frame  1  of  each  epoch) 

Log  of  mess^es  sent; 

Log  of  messages  received 

•  P2PRA  Report  (Sent  in  slot  1  of  frame  1  of  each  epoch) 

Log  of  messages  sent; 

Log  of  messages  received; 

Log  of  messages  vvith  no  known  path  to  destination; 

Routing  metrics  matrix; 

Array  of  next-hop  relay  nodes; 

Array  of  #  hops  on  shortest  paths; 

•  NDDS  Report  (Sent  in  slot  1  of  frame  1  of  each  epoch) 

Log  of  Link-level  performance; 

•  NFSS  Report  (Sent  at  end  of  each  test  cycle) 

Test  Cycle  Index  Number 

For  each  frequency  test  cycle  report  the  following: 

{ 

Frequency  Test  Cycle  Index  Number 
Network’s  bidirectional  connectivities 
Own  Metric 
Test  Frequency 
} 

Best  Metric 
Best  Frequency 

10.1.4.10  Network  Frequency  Selection  Service  (NC_NFSS)  CSC 

The  NC_NFSS  CSC  implements  the  Network  Frequency  Selection  Service  ^dfred  in  section 
5.3.2.1.L1. 

10.1.4.10.1  Network  Frequency  Selection  Algorithm  (NFSA)  CSU 

10.1.4.10.1.1  Network  Frequency  Selection  Algorithm  Design  Specification/Constraints 

Ihe  NFSA  performs  the  following  functions: 

1.  Selects  frequencies  to  be  tested  during  each  test  cycle  of  the  NC.NFSS. 

2.  Sets  transmitter  and  receiver  to  selected  frequetu:y  at  start  of  test  of  that  frequency. 

3.  Disseminates  connectivity  information  throughout  die  network. 

4.  Evaluates  the  frequency  selection  metric  for  each  frequency  tested. 

5.  Disseminates  “best”  frequency  to  other  nodes  in  the  network. 

6.  Sets  transmitter  and  receiva  to  “best”  frequency  at  end  of  test  cycle. 
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10.1.4.10.1.2  Network  Frequency  Selection  Algorithm  Design 
Tliis  subsection  describes  the  design  for  implemendog  these  functions. 


10.1.4.10.1.2.1  Test  Frequency  Selection 

The  following  relations  are  used  to  select  the  set  of  test  frequencies  for  the  ith  activate  cycle  of  the 

NFSS. 


=  {j^}  sequential  collection  of  candidate  frequencies  (EQ  25) 

where  the  jth  element  fj  can  be  <Kxessed  by  the  operator  at  (J)  That  is, 

fj=:F^^MU)  (EQ26) 

Let  A/  be  the  number  of  frequencies  to  be  tested  each  cycle,  and  let  FA  be  ^  stray  of  size  M 
that  holds  the  frequencies  to  be  test^  during  the  rih  active  cycle  of  the  NFSS.  We  shall  assume  that  the 
array  bounds  run  from  0  to  A/  -  1 .  The  last  element  of  FA ^  shall  be  filled  as  follows: 

FA,  =  /  =  ^  (EQ27) 

I  fb.i-i 


where  s  corresponds  o  the  index  of  the  first  active  cycle  of  the  NFSS  at  that  node  (see  figure  3),  and  j  _  j 

is  the  frequency  selected  a  the  “best”  firequency  during  the  previous  active  cycle  of  the  NFSS.  The  f^ 
M-\  elements  of  FA,-  shall  be  filled  from  F^^  as  follows. 

FA.fifc]  =  F,^.flr((i(Af-l) +Jk)%sizeof(F,^)),  0^/nSA/-2  (EQ28) 

where%  is  the  modulo  operator  and  sizeof  ( F^^)  is  the  function  that  returns  the  number  of  elements  in  dK 
collection  F^^. 

10.1.4.10.1.2.2  Set  l^aiisnut  and  Receive  Test  Frequencies 

The  NFSS  calls  routines  in  NC.COM  to  set  die  transmitter  and  receiver  frequencies.  Prior  to  test¬ 
ing  with  each  frequency,  there  is  a  period  of  time  reserved  for  switching  transmitter  and  receiver  frequen¬ 
cies.  (See  figure  7). 

10.1.4.10.1  Disseminate  Connectivity  Information 

The  NFSA  includes  a  variant  of  the  [xotocol  used  by  NCLA  to  disseminate  connectivity  informa¬ 
tion  to  all  nodes  in  the  network.  One  difference  between  the  NFSA  and  NCLA  protocols  for  disseminatii^ 
connectivity  information  is  tte  data  that  is  passed.  The  NCLA  passes  2-bit  Link  (Quality  Indexes  among 
the  nodes,  while  the  NFSA  passes  bidirectional  connectivity  infcmnation.  The  latter  is  encoded  as  1-bit  per 
link.  The  NFSA  Obtains  bitfirecfional  connectivity  information  about  itself  and  adjacent  nodes  from  the 
Periodic  Probing  Algorithm  (PPA);  thereafter,  the  NFSA  pn^iagates  diis  information  to  other  nodes  in  die 
network. 
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Another,  difference  between  the  NFSA  and  NCLA  protocols  for  disseminating  connectivity  infor¬ 
mation  has  to  do  with  the  way  the  coimectivity  database  is  initialized  and  the  length  of  time  that  connectiv¬ 
ity  information,  corresponding  to  a  given  frequency,  is  allowed  to  propagate  throughout  the  network.  In  the 
NFSA,  connectivity  information  corresponding  to  a  given  test  frequency  may  only  by  disseminated  while 
that  frequency  is  being  used.  At  the  end  of  the  period  for  testing  a  given  frequency,  the  metric  correspond¬ 
ing  to  that  frequency  is  computed  and  the  connectivity  database  is  reinitialized. 

The  format  of  the  data  portion  of  an  asynchronous  local  message  that  contains  connectivity  reports 
for  the  NFSA  is  similar  to  that  used  by  the  NCLA,  which  is  shown  in  figure  21.  One  change  is  that  the 
Epoch  ID  shown  in  the  NCLA  data  packet  is  replaced  by  a  Frequency  Index  held,  as  shown  in  hgure  2 1 . 
Another  difference  is  that  the  NFSA  uses  only  one  bit  per  node  to  report  connectivity  information.  Several 
reports  can  be  packed  into  one  message.  Each  report  is  tagged  by  a  frequency  index  that  identihes  the  fre¬ 
quency  for  which  this  report  corresponds.  When  a  connectivity  report  is  received  from  the  PPA,  the  NFSA 
checks  to  see  if  it  represents  different  information  than  is  currently  in  the  node’s  database.  Unchanged  data 
is  not  retransmitted.  The  NFSA  also  decides  whether  to  retransmit  data  received  over  the  air  in  the  form  of 
NFSA  messages.  The  NFSA  performs  this  determination  in  a  way  identical  to  that  used  by  the  NCLA. 
Pseudocode  for  the  NFSA  protocol  for  disseminating  connectivity  information  is  given  in  figures  35  and 
23. 
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a.  Num.  connectivity  reports  (NCR) 

b.  ID  of  orig.  reporting  node 

c.  Frequency  Index 

d.  Bidirectional  Connectivities  Vector 
Additional  connectivity  reports 


NB_NODEJD 

NB_NODE_ID 

NB_FREQ_INDEX 
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} 


NCR 


Data  packet  size  (bits)  NB_NODE_ID+NCR*(NB_NODE_ID+NB_FREQ_INDEX+N) 


Figure  34  Format  of  NFSA  data  packet  for  a  seven  node  (N=7)  network. 


//NFSA  uses  the  following  data  structures: 

Use  RB_neighbors  lists  from  PPA; 

Use  EBB_neighbors  list  from  LCA; 

Integer  current_f req_index; 

Array  ( 1 : NUM_NODES )  of  connectivity_control_blocks, 
each  block  contains  the  following: 

State  is  one  of  (UNINITIALIZED. SAVE, RELAY, SENT, STALE) ; 

List  of  nodes_that_heard_report ; 

List  of  nodes_that_report_must_be_sent_to; 

Integer  freq_index; 

RB_neighbors  of  reporting  node; 

Await  occurrence  of  one  of  the  following  events  and  then  process  it 
CASE  event  is  start_of_frequency_test_cycle: 

Update  current_freq_index; 

Initialize  connectivity_control_blocks; 

CASE  event  is  transmission_opportunity: 

Pack  as  many  reports  as  possible  into  the  NFSA  message, 
that  satisfy  state  ==  RELAY; 

For  each  report  that  is  packed  DO 
states  SENT; 

CASE  event  is  NFSA_connectivity_message_received_from_node_t : 
Unpack  connectivity  reports  for  each 
Call  handle_connectivity_report; 

Case  event  is  network_reorgani2ed: 

Get  own  RB_neighbors  from  PPA; 

Get  EBB.neighbors  list  from  LCA; 

FOR  all  RB_neighbor  reports  received  from  PPA  database 
Call  handle^connectivity_report; 


Figure  35  Pseudocode  for  the  NFSA  protocol  for  connectivity  dissemination. 
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if  report . freq_index  !=  current_freq_index  then 

Ignore  the  report  just  received;  //  this  is  just  a  safety  check 
else  if  report  is  a  duplicate  of  info  in  database  Then 
if  state  !=  sent  then 

Update  nodes_that_heard_report; 

Update  nodes_that_must_be_sent_to ; 

If  nodes_that_inust_be_sent_to  is  en^ty  AND  state  ==  RELAY  Then 
state  =  SAVE; 

else 

Update  RB_neighbors  for  reporting  node; 

nodes_that_heard_report=  RB_neighbors  of  transmitting  node; 
nodes_that_report_must_be_sent_to  = 

(EBB_neighbors-RB_neighbors  of  reporting  node) ; 

If  nodes_that_must_be_sent_to  is  empty  Then 
state  =  SAVE 
else 

state  =  RELAY; 

Hgure  36  Pseudocode  for  NFSA  procedure  handle_connectivity_teport  from  node  t. 


10.1.4.10.1.2.4  Frequency  Selection  Metric 

There  are  several  considerations  that  go  into  the  selection  of  the  “best”  frequency.  For  example,  is 
the  network  fully  connected,  that  is,  are  there  communication  paths  between  all  no^?  Are  connectivities 
among  certain  nodes  more  important  than  connectivities  among  other  nodes?  How  many  relays  are 
needed?  Which  frequency  results  in  the  highest  through{nit  or  the  smallest  message  delays? 

In  this  implementation  of  the  NFSS  we  define  the  “best”  frequency  as  the  one  that  minimizes  the 
frequency  selection  metric.  Figure  37  defines  frequency  selection  Metric  A,  which  was  the  one  initially 
formulated  and  tested  (see  section  14.4.1.1).  Metric  A  is  ^ven  in  the  form  of  an  integer  expressed  in  binary 
format.  The  most  significant  bit  is  on  the  left.  The  “best”  frequency  is  the  one  that  minimizes  this  metric. 
Thus,  the  most  important  factor  in  this  metric  is  the  number  of  uncoruiected  nodes,  i.e.,  nodes  that 
are  disconnected  from  the  largest  component  of  the  network.  This  implementation  attempts  to  choose  the 
frequency  that  leaves  the  fewest  nodes  ^scoruiected  from  the  largest  component  of  the  tetwork.  If  several 
frequencies  result  in  the  same  number  of  unconnected  nodes,  the  best  frequency  is  the  one  that  requires  the 
fewest  number  of  relay  nodes  on  the  backbone  network.  This  will  maximize  performance  of  a  HAMA  net- 
wcnrk.  The  least  significant  component  in  the  frequency  selection  metric  is  the  index  of  the  frequency  in  the 
sequential  collection  of  candidate  frequencies 

After  simulation  tests,  it  became  obvious  that  Metric  A  did  not  satisfactorily  distinguish  among 
network  topologies  that  resulted  in  similar  backbone  networks.  As  a  consequence  Metric  B  was  defined  to 
conect  diis  deficiency.  Metric  B  is  defined  in  the  notes  found  in  section  10.3.8.1. 
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Fifuie  37  Pomut  of  frequency  lelecdon  Metric  A. 


The  pseudocode  given  in  figure  38  can  be  used  to  find  the  connected  components  of  the  network,  lypi- 
cally,  we  would  expect  that  the  network  would  have  only  one  component  at  the  “best"  frequency  In  die 
pseudocode  of  figure  38  we  introduce  two  sets  to  hold  intermediate  results.  [TN)  is  the  set  of  nodes  of  the 
component  being  built,  and  { FA }  is  the  set  of  nodes  whose  adjacencies  have  been  considered  by  the  algo¬ 
rithm.  The  components  of  the  network  are  put  into  {C}.  We  define  the  fimction  sizeofMaxComp  as  the 
function  that  returns  the  number  of  elements  in  the  largest  component  of  {C}.Thus,  the  equation 

^  "  SizeofMaxComp  ( { C} )  (EQ  29) 

provides  the  most  significant  field  in  the  frequency  selection  metric. 


Given;  the  undirected  graph  <V,E> 

Find;  the  components,  {C},  of  <V,E> 

{C}  =  empty  set; 

{W}  =  {1,2 . N}; 

while  ({W}  is  not  empty) 

{  {TN}  =  {TA}  =  empty  set; 

transfer  element  el  from  {W}  to  {TN}; 
while  ({TN}  1=  {TA}) 

{  select  an  element  el2  from  {TN}  -  {TA} ; 

transfer  all  neighbors  of  el2  from  {W}  to  {TN} ; 
insert  el2  in  {TA} ; 

} 

insert  copy  of  {TN}  into  {C}; 


Rgure  38  Pieudocode  to  find  die  componesUof  an  undirected  gr^ib. 
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To  find  the  next  most  significant  field  in  the  frequency  selection  metric,  the  algorithm  given  in  fig¬ 
ure  39  is  used.  This  algorithm  approximates  the  minimum  backbone  network  (MBN)  of  the  largest  compo¬ 
nent  of  the  network.  The  term  which  appears  in  the  frequency  selection  metric,  is  the  number  of 
nodes  in  this  aj^roximation  of  tte  minimum  backbone  network  for  the  largest  connected  component. 

find  clusterheads,  boundary  nodes,  and  terminator  nodes  using  the  LCA 

initialize  MBN  to  empty  set 

while  MBN  is  not  connected  to  all  nodes 

find  non-terminator  node  that  adds  maximal  neighbors  to  MBN 
add  this  node  to  MBN 
weight  each  link  (i,j)  as  follows: 

case  (i,j)  unconnected:  weight  INFINITY 
case  i  or  j  is  TERMINATOR  node:  weight  INFINITY 
case  i  and  j  on  MBN  weight  1 
case  i  on  MBN  or  j  on  MBN  weight  10 
otherwise  weight  100 
find  shortest  paths  across  network 
use  paths  generated  to  connect  MBN 
add  nodes  used  to  connect  to  MBN 

Figure  39  Pseudocode  for  finding  the  backbone  network. 


Bnally,  as  a  'tie-breaker”,  the  least  significant  field  in  the  selection  metric  is  filled  with  the  index 
of  the  frequency  in  the  sequential  collection 

10.1.4.10.1.2.5  Protocol  for  Disseminating  **Besf  ’  Frequency  Metric 

The  protocol  for  disseminating  the  metric  for  the  “best”  frequency  is  similar  to  that  use  by  the 
Congestion  Control  Algorithm  to  disseminate  the  network  traffic  limit,  g  (see  section  10.1.4.7.1.2).  The 
pseudocode  for  this  protocol  is  shown  in  figures  31  and  32.  The  messages  containing  the  “best”  frequency 
metric  ^lall  have  precedence  over  the  connectivity  messages  sent  by  the  NFSA. 


//Data  Structures  Used 

Use  RB_neighbors  lists  from  PPA; 

Use  EBB_neighbors  list  from  LCA; 

unsigned  int  own_metric; 

enum  local_bc_msg_cntrl^blk_state 

{UNINITIALIZED, INITIALIZED, SAVE, RELAY, SENT, STALE} ; 
struct  nfss_metric_msg_control_block  { 
unsigned  int  metric; 

List  nodes_that_heard_metric ; 

List  nodes_that_metric_must_be_sent_to; 
local_bc_insg_cntrl_blk:_state  state;}  cblk; 

Await  occurrence  of  one  of  the  following  events, 
then  process  as  indicated  below: 
case  startup: 

cblk. metric  =  SHRT_MAX;  //SHRT_MAX  =  32767  =  0x7FFF 
cblk.nodes_that_heard_metric  =  EMPTY; 
cblk.nodes_that_metric_must_be_8ent_to  =  EMPTY; 
cblk.state=INITIALIZED; 
case  con^ute_metric : 

confute  own_metric; 
case  begin_flood_of_best_metric; 
cblk.metric=own_metric; 
cbl k . s ta t e =RELAY ; 

case  r3ceived_A»etric_msg  from  node  t 
handle_jnetric_msg(t,  rcvd_metric)  ; 
case  network_reorganized: 

Get  RB_neighbors  of  all  nodes  from  PPA; 

Get  EBB.neighbors  list  from  LCA; 

cblk.nodes_that_jiietric_mu3t_be_sent_to  =  EBB_neighbors; 
cblk. state  =  RELAY; 
case  transmi8sion_opportunity^: 
if  (cblk. state  s=  RELAY)  { 

send  cblk. metric  in  a  local  message; 
cblk. state  =  SENT;} 


Figure  40  Pseudocode  for  dte  disseminating  the  ‘‘best”  metric. 


1 .  This  conespoods  to  any  transmission  slot  for  the  host  node  after  the  first  ftequency  test  cycle  and  exclusive  of 
slots  in  frames  1  and  2. 


10.1.4.10.1.2.6  Installation  of  Selected  Frequeno^ 

Hie  NFSS  calls  routiiies  in  NC_COM  to  set  the  transmitter  and  receiver  to  the  frequency  selected 
as  die  “best”  frequency.  Tuning  for  tlfis  is  shown  in  figure  7. 
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procedure  handle_metr ic_msg < int  t,  unsigned  short  int  rcvd_metric ) 
//  t  is  the  id  of  transmitting  node 
{ 

if  (rcvd_metric  >  cblk. metric) 

;  //Ignore  the  message  just  received; 
else  if  rcvd_metric  ==  cblk. metric)  { 
if  <cblk.state!=3ent)  { 

Update  cblk . nodes_that_heard_msg ; 

Update  cblk .  nodes_that_mu&  c_be_sent_to .* 
if  (cblk.nodes_that_must_be_sent_to  is  empty  AND 
(cblk. state  ==  RELAY  OR  cblk. state  ==INITIALIZED) ) 
cblk.state=  SAVE;} 
else  {//rcvd_metric  <  cblk.gn 

Clear  cblk.nodes_that_heard_msg; 
cblk.nodes_that_must_be_sent_to  =  EBB  neighbors; 
cblk. state  =  RELAY; 

Update  cblk . nodes_that_heard_msg ; 

Update  cblk . nodes_that_report_must_be_sent_to ; 

If  (cblk.nodes_that_must_be_sent_to  is  empty) 
cblk. state=SAVE} 

} 


Figure  41  Pseudocode  for  Procedure  handle_inettic .jnsg. 


10.1.4.11  NC^RT  Timing  Control  (NC.TC)  CSC 

The  NC_TC  CSC  implemems  timing  control  for  the  real-time  component  (NC_RT)  of  the  Net¬ 
work  Controller. 

10.1.4.11.1  Timing  Controller  (TC)CSU 

10.1.4.11.1.1  Timing  Controller  Design  Specification/Constraints 

The  Timing  Controller  performs  the  following  functions: 

1.  Provides  for  the  scheduling  and  calling  of  time-scheduled  procedure  calls. 

2.  Provides  other  modules  with  timing  information  contained  in  system  timing  figures  3, 7,  and  19. 

10.1.4.11.1.2  Tming  Controller  Design 
TBD. 

10.1.4.12  NC.RT  Startup  (NC.RT^SU)  CSC 

Hie  NC_RT_SU  CSC  implements  those  procedures  necessary  to  get  the  real-time  conqionent 
(NC_RT)  of  the  Network  Controller  in  operatioa 
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10.1.4.12.1  NC_RT  Main  (NC_RT_MAIN)  CSU 

10.1.4.12.1.1  NC_RT  Main  (NC_RT_MAIN)  Design  Specification/Constraints 

The  NC_RT_MaiN  CSU  performs  the  following  functions: 

1.  Creates  all  NC_RT  software  objects. 

2.  Calls  startup  procedures  in  each  object  of  NC_RT  after  all  objects  have  been  created. 

10.1.4.12.1.2  NC_RT  Main  Design 
TBD 

10.1.4.13  NC_NRT  Startup  (NC_NRT_SU)  CSC 

The  NC_RT_SU  CSC  implements  those  procedures  necessary  to  get  the  non-real-time  component 
(NC_NRT)  of  the  Network  Controller  in  operation. 

10.1.4.13.1  NC_NRT  Main  (NC^NRT.MAIN)  CSU 

10.1.4.13.1.1  NC.NRT  Main  (NC.NRT.MAIN)  Design  Specification/Constraints 

The  NC_NRT_MAIN  CSU  performs  the  following  functions: 

1.  Creates  all  NC_NRT  software  objects. 

2.  Calls  startup  procedures  in  each  object  of  NC_NRT  after  all  objects  have  been  created. 

10.1.4.13.1.2  NC.NRT  Main  Design 
TBD 

10.1.4.14  IP  Connection  (NC_IP_CONN)  CSC 

The  NC_TC  CSC  implements  timing  control  for  the  real-time  component  (NC_RT)  of  the  Net¬ 
work  Controller. 

10.1.4.14.1  IP  Driver  aP^DRIVER)  CSU 

10.1.4.14.1.1  IP  Driver  Design  Spedfication/Constraints 

The  IP  Driver  shall  provide  an  interface  between  the  Internet  Protocol,  which  is  part  of  the  host 
operating  system,  and  the  NI^E  System’s  internal  network. 

10.1A14.1J  IP  Driver  Design 

The  IP  Driver  design  shall  conform  to  the  network  interface  driver  design  described  in  [12]. 
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10.1.4.15  LC  Connection  (NC_LC_CONN)  CSC 

The  NC_LC_CONN  CSC  implements  that  part  of  the  IF_NC_LC  interface  that  resides  in  the  Net¬ 
work  Controller.A  single  CSU,  the  Network  Data  Distribution  System  (NDDS),  is  used  to  implement  the 
LC  Connection. 

10.1.4.15.1  Network  Data  Distribution  System  (NDDS)  CSU 

10.1.4.15.1.1  NDDS  Design  Spedfication/Constraints 

The  NDDS  CSU  design  specification/constraints  are  given  in  [1 1].  A  summary  of  these  also 
appears  in  section  11.3.2. 

10.1.4.16  Real-time  Output  Server  (NC_RTO_SV)  CSC 

The  NC_RTO_SV  CSC  handles  the  writing  to  file  of  data  that  has  been  placed  in  shared  memory 
by  the  NC_SIM  CSU  file  output  facilities. 

10.1.4.16.1  NC  Output  Server  (NC_0_SV)  CSU 

10.1.4.16.1.1  NC  Output  Server  Design  Specification/Constraints 
TBD 

10.1.4.16.1.2  NC  I/O  Server  Design 
TBD 

10.1.4.17  NC  Sim++  Interface  (IF.SIM)  CSC 

The  IF_SIM  CSC  implements  a  portion  of  the  Sim-H-  software  from  Jade  Simulations  Interna¬ 
tional  (JSI)  on  a  vxWorks  target  MVME135A  CPU. 

10.1.4.17.1  NCSim++(NC_SIM)CSU 

10.1.4.17.1.1  NC  Sim++  Design  Spedfication/Constraints 
TBD 

10.1.4.17.1.2  NC  Sim++  Design 
TBD 
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10.1.4.18  DSPT  Interface  (IF.DSPT)  CSC 


The  IF_DSPT  CSC  implements  a  portion  of  the  DSPT  software  fix>m  NRL  on  a  vxWorks  target 
MVME135ACPU. 

10.1.4.18.1  NC  DSPT  (NC.DSPT)  CSU 

10.1.4.18.1.1  NC  DSPT  Design  Spedfication/Constraints 
TBD 

10.1.4.18.1.2  NC.DSPT  Design 

This  subsection  describes  the  design  for  implementing  these  functions. 

10.1.4.19  Tlraffic  Source/Sink  (NC_SRC_SNK)  CSC 
TBD 

10.1.4.20  NC  Timing  Control  (NC_TC)  CSC 

The  NC_TC  CSC  implements  timing  control  for  the  real-time  component  (NC_RT)  of  the  Net¬ 
work  Controller. 

10.1.4.20.1  Timing  Controller  (TC)  CSU 

10.1.4.20.1.1  Uming  Controller  Design  Spedfication/Constraints 
TBD 

10.1.4.20.1.2  Timing  Controller  Design 
TBD 

10.1J  NC  Data 

The  NC  relies  on  data  files  for  both  iiqnit  and  output.  This  subsection  identifies  these  files,  indi¬ 
cates  whidi  CSC/CSUs  use  each  file,  and  describe  the  file  formats. 

10.1.6  NC  Data  Files 

The  iiqnit  files  used  by  the  NC  are  as  follows: 

complan.inp 

timing.inp 

nc_vx_startinp 
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message.inp 
flags,  trace 
nfss.inp 

With  the  exception  of  complan.inp,  the  input  files  are  the  same  at  all  nodes.  The  NC  uses  the  same 
input  files  during  simulation/emulation  tests  as  it  does  in  the  held  tests.  For  this  reason,  some  of  the  param¬ 
eters  that  are  found  in  the  input  files  have  significance  only  when  the  NC  is  being  tested  in  the  simulator/ 
emulator. 

The  NC  uses  the  output  files  listed  below. 

log.out 

statout 

cksum_blk_rcvd.out 

cksum_blk_good.out 

msg.trace 

10.1.6.1  Data  File  to  CSC/CSD  Cross  Reference 

10.1.6.2  ComplanJnp 

Figure  42  is  an  example  of  a  typical  complan.inp  hie.  One  item  in  this  hie  that  is  unique  to  each 
node  is  the  node  id,  on  line  2.  Figure  42  shows  the  complan.inp  file  for  node  2. 
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1.1  Version  of  con^lan  (do  not  change) 

2  Node  id 

1  Send  on  ftdina  only  (true  =  1,  false  =  0) 

0  Send  ntds  using  local  nisgs  (true  =  1,  false  =  0) 

7  Number  of  nodes  in  network 

0  0=start  at  4-epoch  boundary  ;  l=start  at  time  given  below 
0000  (hr  min  sec  ma)  Time  network  is  to  start  operating 
01  01  1970  (mo  day  yr)  date  network  is  to  start  operating 
01  01  1970  (mo  day  yr)  today's  date 

10000  000  (hr  min  sac  ms)  Period  network  is  to  operate 
1  Max.  number  of  xmtrs  that  can  be  allocated  this  network 
1  Number  of  xmtrs  allocated  this  network 
1  Set  of  xrotr  ids  allocated  this  network  (integers) 

1  M2UC.  number  of  rcvrs  that  can  be  allocated  this  network 
1  Number  of  rcvrs  allocated  this  network 
12345  Rcvr  ids 
0  xmit  code  number  (1  ... 

40  xmtr  power  in  watts 
0  rev  code  number  (1  .... 

0  AUTOMATIC_CONGESTION_CONTROL  (l=ON,  0*OFF) 

0.0  10  0.05  1.0  init  traf  lim(sl/fr) , inc  period (epochs ), inc,  max 
13579  seed  for  traffic  limit;  //Added  9/8/89  by  djb 
0  use_icm  0=don't  use  l=u8e 

Figure  42  Sample  coraplanJnp  file  fix>m  node  2. 
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10.1.6.3  Tiiiung.inp 


The  timing.inp  hies  contains  values  for  most  of  the  parameters  that  control  network  timing.  Figure 
43  shows  a  sample  timing.inp  file. 

1.2  Version  of  timing.inp  (do  not  change) 

2400  xmtr  info  rate  (e.g.  2400bps) 

1056  xmtr  packet  length  (data  only  -  no  cksum  bits) 

0  xmtr  interleaver  depth 

2400  rcvr  info  rate  (e.g.  2400bps) 

1056  rcvr  packet  length  (data  only  -  no  cksum  bits) 

0  rcvr  interleaver  depth 

4  TI^  frames  between  epochs  (integer,  range  >  3) 

7  Number  of  slots  per  ftdma  frame 

6  num_cksum_blks_per_siot 

650.  t_f tdma_slot_duration  (ms)  570  600 

30.  t_tune_rcvr  (ms)  relative  to  start  of  slot 

-10.  t_detune_rcvr  (ms)  relative  to  next  t_tune_rcvr  time 

-200.0  T_PPA_INITIALIZATION  //w.r.t.  end  of  epoch 

-195.0  T_LCA_INIT1ALIZATI0N  //w.r.t.  end  of  epoch 

-190.0  T_TSA_ INITIALIZATION  //w.r.t.  end  of  epoch 

-185.0  T_RSA_INITIALIZATION  //w.r.t.  end  of  epoch 

-180.0  T_PPA_LOAD_XMIT_BUFFER  //W.r.t. 

-175.0  T_LCA_LOAD_XMIT_BUFFER 
-170.0  T_TSA_LOAD_XMIT_BUFFER  //W.r.t. 

-165.0  T_CCA_LOAD_XMIT_BUFFER  //W.r.t.  start  of  transmission  slot 
-90.0  T_TBMA_LOAD_XMIT_BUFFER  //w.r.t.  start  of  transmission  slot 
-80.0  T_SEND_PACKET  (-80.0) 

-0.4  T_INSTALL_CLUSTERS  //w.r.t.  end  of  frame  2 

5.0  T_PPA_REPORT_UPDATE  //w.r.t.  end  of  frame  2 

5.0  T_LCA_REPORT_UPDATE  //w.r.t.  end  of  frame  2 

-10.0  T_CAA_REPORT_UPDATE  //w.r.t.  start  of  frame  4 

5.0  T_NCLA_REPORT_UPDATE  //w.r.t.  end  of  frame  2 

5.0  T_CCA_REPORT_UPDATE  //w.r.t.  end  of  frame  2 

-7.0  T_RSA_REPORT_UPDATE  //w.r.t.  end  of  epoch 

240.0  T_NSMA_REPORT_STATUS  //w.r.t.  end  of  epoch  (-6.0) 

10.0  T_IC:m_POST_STATS  //w.r.t  start  of  current  frame 

350.0  T_READ_RCV_BUFFER  //w.r.t.  start  of  current  slot  (240.0) 

-234.0  T_RCVR_TUNING  / /w.r .t .start  of  next  slot  -  sched  time  for 
635.0  T_RTS_DURATION  (534.0)  547  575 
0.0  T_RTS  /‘time  to  raise  rts  line  */ 

Hgise  43  Timing-inp  file. 
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10.1.6.4  nc.vx.startinp 

The  nc_vx_starLinp  hie,  shown  in  Figure  49.  contains  parameters  for  setting  the  simulation  dura¬ 
tion  (when  the  NC  is  being  tested  in  simuiation/emulation  mode)  and  for  setting  the  period  between  statis¬ 
tics  reporting  to  the  stat.out  hie.  All  times  are  given  in  milliseconds  in  nc_vx_startup.ii^). 

1500000.0  //sinperiod  in  simulation  time  units 
182000.0  //report  update  period  in  simulation  time  units 

Figure  44  iic_vx_ttaitjnp  file. 


10.1.6.5  Messageinp 

The  m^age.inp  hie  contains  canned  messages  for  insertion  into  new,  dummy  traffic.  The  hrst  line 
in  this  hie  contains  text  that  is  inserted  into  broadcast  messages,  and  the  second  line  contains  text  that  is 
inserted  into  some  local  messages.  Local  messages  are  meant  for  nodes  that  are  within  direct  range  of  die 
transmitting  node,  that  is.  they  are  messs^es  that  are  not  intended  to  be  relayed  by  the  network. 
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10.1.6.6  Flag&trace 

Information  in  the  file  flags.trace  is  used  to  control  what  information  is  displayed  on  the  console 
(hiring  tests  and  what  gets  archived.  An  example  of  flags  set  for  a  field  test  are  shown  in  Figure  45. 


1  0  TRACE_EVP 

2  1  TRACE_LCyt 

3  0  TRACE_CAA 

4  0  TRACE_RSA 

5  1  TRACE_CCA 

6  0  TRACE_NCLA 

7  1  TRACE_TBMA 

8  0  TRACE_RBMA 

9  0  TRACE_P2PRA 

10  0  TRACE_BTRA 

11  0  TRACE_NSMA 

12  0  TRACE_NDDS 

13  1  TRACE_PPA 

14  0  TRACE_TC 

15  0  TRACE_TC_NODE  ( l*trace_all_nodes,  0=trace_node_l) 

16  0  TRACE_VALUES 

17  0  TRACE_NTDSP 

18  0  TRACE_IP 

19  0  TRACE_MODEM 

20  0  TRACE_I<a4 

21  1  LOG_PPA 

22  1  LCX3_LCA 

23  1  I,OG_CCA 

24  1  LCX3_NCLA 

25  0  IiOG_LINK_RCV_RATE 

26  1  LOG_MSGS 

29  0  TRACE_XMIT_FRAMES 

30  0  TRACE_RCnnD_FRAMES 

31  1  TRACE JISGS 

32  0  TRACE_RCVR_USAGE 

33  0  TRACE_CKSUM_BLK_ ERRORS 

34  0  TRACEJTIMINGS 

35  0  TRACE_RCV_BIiKS 

36  0  TRACE_BLKS_NOT_RCVD 

37  1  TRACE_LINK_RCV_RATE 
999 


Figure  45  llags.tFace  file  used  (falling  mtt. 
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10.1.6.7  Nfss.inp 


The  hie  nfss.inp  is  used  to  input  the  candidate  frequencies  to  the  NFSE  System.  Figure  46  illus¬ 
trates  the  format  for  this  file.  Frequencies  are  entered  in  kilohertz,  one  frequency  per  line.  The  frequency 
list  is  terminated  with  a  -1. 


A 

0 

2862.0 

4292.0 

5312.5 

5751.5 
5915.0 

6369.5 
8566.0 
8578.0 
9250.0 
-1 


//Mode  of  operation:  A. 
//Use  internal  network: 


B.  or  C 
0=No.  l=Yes 


Figure  46  Samite  nfss.inp  file. 


10.1.6.8  Log.out 

Figure  47  shows  a  sample  of  a  data  written  to  the  log.out  file  at  node  2  every  epoch,  i.e.,  each  time 
the  network  reorganizes.  These  traces  contain  information  about  the  network  connectivities  and  the  net¬ 
work  control  structure.  To  fully  understand  the  meaning  of  these  outputs  the  reader  should  consult  [3]. 

The  first  line  shown  in  the  example  appears  only  if  the  NFSE  System’s  internal  network  is  operat¬ 
ing  and  Congestion  Control  is  turned  on,  and  in  that  case  it  only  appears  every  other  epoch.  The  time  of  the 
status  report  is  given  as  the  millisecond  of  the  day  Greenwich  Mean  Time  (GMT).  For  example,  the  time 
78915440  shown  in  the  sample  report  corresponds  to  21h:S5m:lS.264s  (GMT). 

Next  in  the  output  file  is  a  listing  of  die  reliable  bidirectional  neighbors  (RBN)  of  each  node.  Each 
row  following  the  “RBN;”  heading  conesponds  to  a  report  of  RBN  for  nodes  1  to  7,  respectively.  The  con¬ 
nectivities  are  displayed  as  a  hexadecimal  representation  of  a  32-bit  integer  with  leading  zeros  suf^nessed. 
To  “read”  the  connectivities,  it  is  first  necessary  to  convert  this  hexadecimal  number  to  the  corresponding 
32-bit  binary  equivalent.  The  most  significant  bit  in  the  resultant  binary  number  ref^esents  fire  existence  or 
absence  of  a  link  to  node  1 ;  the  second  bit  represents  the  existence  or  absence  of  a  Unk  to  imde  2,  etc.  Thus, 
forexample,  the  hexadecimal  value  of  400 0000  inrow  1  (i.e.,(X)(X)01(X)  0000 (X)00  (XXX)  (XX)0(X)(X)00(X) 
binary)  indicates  that  node  1  had  a  reliable  bidirectional  link  only  to  node  6,  since  only  the  6di  bit  is  set  to 
“1”.  ^ote  from  the  example  that  leading  zeros  in  the  32-bit  hexadecimal  value  are  not  printed.)  If  (he 
reporting  node  is  out  of  range,  or  if  the  reporting  tKxle  has  no  RB-neighbors,  a  zero  is  printed  in  that  row.  A 
similar  format  is  used  to  report  on  the  probes  heard  during  the  last  network  reorganization;  this  information 
follows  the  RBN  list  In  this  example,  node  2  has  heard  probes  from  nodes  1, 3, 6,  and  7.  However,  check¬ 
ing  node  2’s  RBN  row,  we  see  that  the  link  between  nodl»  1  and  2  is  not  a  reliable,  bidirectional  one. 
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Installing  traffic  limit  =  0.086274  at  node  2 
Status  report  for  node  2  at  time  78915440.000000 
RBN; 

4000000 

26000000 

46000000 

0 

0 

eOOOOOQO 

68000000 

Probesheard:  a6000000 


LCA:  • 

nodestatus  =  0 
hdslhop  s  0 
hds2hcps  =  80000000 
EBBN  =  26000000 
ownhead  =  2 
NCLA: 

LQI: 

300000 

c3c0000 

303c0000 

0 

cOOOO 

fcOOOOOO 

3cc00000 

Hguie  47  Sample  of  the  data  written  after  each  reorganization  epoch  to  the  k>g.oiit  file  for  node  2. 

Next  follows  tbe  report  by  the  Linked  Ouster  Algorithm  (LCA).  The  start  of  this  report  is  indi¬ 
cated  by  the  heading  "LCA:”.  The  LCA  report  gives  a  good  indication  of  how  the  network  is  organizing 
itself  locally.  The  nodestatus  tells  whether  the  reputing  node  is  a  clusterhead  (0),  boundary  node  (1),  or  a 
terminator  node  (2).  At  the  time  this  sample  report  was  made,  node  2  had  assumed  die  role  of  a  cluster- 
head.  Following  the  nodestatus  are  three  lines  of  information  giving:  1)  dusterheads  one-hop  away,  2) 
clusterheads  two-hops  away,  and  3)  a  list  of  nodes  that  are  the  reporting  node’s  neighbors  in  the  enhanced 
backbone  network  (I^BN).  Nodes  that  are  one-hop  away  can  be  reached  direcdy,  and  nodes  diat  are 
within  two-liops  can  be  reached  via  a  single  relay  node.  The  formats  of  these  three  reports  are  the  same  as 
for  the  RBN.  The  neighbors  on  tbe  EBBN  are  those  nodes  to  indiich  the  reporting  node  will  relay  broadcast 
traffic.  Thus,  from  die  sample  output,  mde  2  has  no  clusterheads  within  one  bop  (whidi  is  to  be  expected 
siiiceiiode2isaclusteffiead).andnode2isawaiethatiK)de  1  is  a  clustohead  that  is  two-hops  away.  Also, 
node  2  will  seek  to  relay  broadcast  traffic  to  nodes  3, 6,  and  7,  as  required.  Finally,  on  the  next  line  of  out¬ 
put,  the  LCA  reports  the  identity  of  its  “own”  clusterhead,  ^^cfa  in  this  exam{de  is  node  2  itself. 

Next  is  die  report  from  die  Network  Connecdvity  Learning  Algorithm  (NCLA).  This  report  begins 
widi  die  header  “NCLA:  ”.  What  follows  is  a  report  of  die  Link  (Quality  Indexes  (LQI)  for  each  node  in  die 
network — one  row  per  node.  Thus,  row  1  isareponofthequaliqrofalliiicoininglinksatnode  l;iow2 
is  a  similar  report  fiir  node  2,  etc.  Again  the  infrxmation  is  presented  as  a  hexadecimal  integer  (32-bits) 


to* 


with  leading  zeros  suppressed.  However,  unlike  the  RBN  infoim^on.  two  bits  are  used  to  represent  the 
quality  of  a  link.  For  example,  the  hexadecimal  value  c3c0000  (i.e..  0000110000  11  11000000  0000 
00  00  00  00  binary)  in  the  second  row  would  indicate  that  node  2  has  LQI=3  (binary  1 1.  the  highest  qual* 
ity)  on  links  from  nodes  3. 6,  and  7.  Note  that,  unlike  the  RBN  information,  which  is  available  only  from 
neighboring  nodes,  the  NCLA  coimectivity  information  is  usually  available  for  all  nodes.  Thus,  for  exam¬ 
ple,  node  2  knows  of  node  S’s  connectivities  even  though  it  cannot  hear  node  S  directly. 

The  NFSA  CSU  also  writes  to  the  log.out  hie;  it  does  so  at  the  end  of  each  test  cycle.  The  format 
of  this  report  is  illustrated  in  figure  47.  The  first  line  identifies  the  reporting  node  and  the  time  at  which  the 
report  was  written.  The  second  line  is  a  decimal  number  identifying  the  test  cycle  for  which  this  report 
applies.  For  each  frequency  test  cycle  the  following  appears:  frequency  test  cycle  id  (decimal),  the  bidirec¬ 
tional  connectivities  known  by  the  node  (RBN  format),  the  metric  (hexadecimal)  computed  at  this  node, 
and  the  test  frequency  (kilohertz).  Following  that  the  NFSA  reports  the  “best”  metric  (hexadecimal)  and 
the  “best"  frequency  (kilohertz). 

NFSS  report  for  node  2  at  time  78915440.000000 
Test  Cycle  875 
Frequency  Test  Cycle  0: 

Topology; 

4000000 

26000000 

46000000 

0 

0 

eOOOOOOO 

68000000 

Own  metric;  2081 
Test  Frequency;  4292.0 
Frequency  Test  Cycle  1: 

Topology; 

4000000 

26000000 

46000000 

0 

0 

eOOOOOOO 

68000000 

Own  metric;  2082 
Test  Frequency;  5312,5.0 
Best  Metric;  2081 
Best  Frequency;  4292.0 


Figure  48  Samide  of  the  data  written  by  ifae  NFSA  CSU  to  the  log.out  file  for  node  2. 
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10.1.6.9  Statout 


This  file  contains  all  the  statistics  collected  during  the  tun.  Each  line  of  ouqnit  in  the  statout  hie 
contains  the  following:  1)  time  statistic  was  written  to  hie,  2)  type  of  statistic  being  reported.  3)  platform, 
node,  and  object  numbers  of  reporting  object,  4)  object  type,  5)  number  of  observations  being  reported,  6) 
average,  maximum,  minimum,  and  standard  deviation  for  the  statistic  being  reported. 

10.1.6.10  Cksum_blk_rcvd.out 

The  Network  Controller  records  in  this  hie  whether  each  block  is  received  or  not  by  the  reporting 
node.  A  sample  line  from  this  output  hie,  written  at  node  2,  is  shown  in  Figure  49.  The  hrst  integer  indexes 
the  epoch  being  reported.  In  this  example,  the  report  is  for  the  3S7  th  epoch  recorded  in  this  hie.  The  next 
integer  is  the  millisecond  of  the  day  (GMT)  that  this  epoch  started.  Following  that  is  information  about 
which  blocks  were  received  by  node  2  during  the  epoch.  This  infOTtnation  is  output  as  an  array  of  six  hexa¬ 
decimal  32-bit  integers  with  leading  zeros  suppressed.  Each  bit  represents  one  transmission  block.  A  1 
means  the  block  was  received  and  a  0  means  the  block  was  not  received.  During  each  transmission  slot  a 
node  transmits  6  blocks.  There  are  7  slots  per  frame  and  4  frames  per  epoch  for  a  total  of  168  blocks  per 
epoch.  Thus,  the  last  6  zeros  (representing  24  bits)  on  each  line  are  to  be  neglected  since  they  do  not  repre¬ 
sent  any  connectivity  information.  The  sample  printout  shows  that  node  2  received  all  blocks  from  nodes  I . 
3, 5. 6,  and  7  and  no  blocks  from  itself  or  node  4  during  each  of  the  four  frames  of  this  epoch 

357  78915200.000000  FCOFCOFF  FFFF03F0  3FFFFFC0  FCOFFFFF  F03F03FF  FFOOOOOO 
Figure  49  Sample  line  of  output  from  cksum.blk^vd.out  at  node  2. 


10.1.6.11  Cksuin_blk_£ood.out 

The  file  cksum_bIk_good.out  is  arranged  in  the  same  format  as  cksum_blk_rcvd.ouL  However,  in 
cksum_bIk_good.out  we  record  the  results  of  the  checksum  test  on  each  received  block.  A  1  indicates  the 
block  was  received  with  the  correct  checksum,  and  a  0  indicates  that  either  the  block  was  not  received  or  it 
was  received  with  an  incorrect  checksum.  Together.  cksum_blk_rcvd.out  and  cksum_blk_good.out  charac¬ 
terize  the  overall  behavior  of  the  link  layer  of  the  Network.  For  the  example  shown  in  figures  49  and  49.  all 
the  blocks  received  horn  nodes  1  and  6  were  received  correctly.  The  following  blocks  were  received  with 
checksum  errors:  frame  1)  blocks  1. 2, 4,  and  5  from  node  5  and  block  1  from  node  7,  frames  2, 3,  and  4) 
all  blocks  from  node  S. 

357  78915200.000000  FC0FC027  F7FF03F0  FFFFCO  FC003FFF  F03F000F  FFOOOOO 


Figure  50  Sample  line  of  output  from  c]csum_blk_good.out  at  node  2. 


10.1.6.12  Msg.trace 

The  msg.trace  file  contains  a  line  of  output  for  each  message  transmitted  or  received  by  the  Net¬ 
work  Controller.  More  precisely,  this  file  records  those  messages  that  were  received  by  the  Broadcast  Traf¬ 
fic  Routing  Algorithm.  Hgure  49  is  a  small  excerpt  from  a  sample  msg.trace  file  at  node  1 .  Each  line  is 
formatted  as  follows:  id  of  reporting  node,  software  module  id  (see  Figure  49),  event  type  (see  Figure  49), 
time  event  occurred,  message  type  (see  Figure  49),  original  creator  of  die  message,  and  message  sequence 
number.  Thus,  for  example,  the  first  line  of  ouqxit  in  figure  49  incficates  that  the  Transmit  Buffer  Manage¬ 
ment  Algorithm  (TBMA)  was  responsible  for  transmitting  a  broadcast  message  (the  74  th  message  gener- 
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ated  at  node  1  since  the  last  start-up)  at  time  80134510.  The  second  line  of  output  indicates  that:  the 
Broadcast  Traffic  Routing  Algorithm  (BTRA)  at  node  1  received  a  broadcast  message  for  processing  at 
time  80134700.  This  message  was  the  24  th  message  generated  by  node  5.  Likewise,  line  4  says  that  node 
1  relayed  this  message  at  time  80139060. 
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1  60  0  80134510.000000  1  1  74 
1  90  2  ,80134700.000000  1  5  24 
1  90  2  80138600.000000  1  6  262 


1  90  1  80139060.000000  1  5  24 


Figure  51  Sample  output  from  msg. trace  at  node  1. 


♦define  NC_PPA  0 
♦define  NC.LCA  10 
♦define  NC_CAA  20 
♦define  NC_RSA  30 
♦define  NC_CCA  40 
♦define  NC_NCLA  50 
♦define  NC_TBMA  60 
♦define  NC_RBMA  70 
♦define  NC_P2PTRA  80 
♦define  NC_BTRA  90 
♦define  NC_NSMA  100 
♦define  NC_NDDS  110 
♦define  NC_NTDSP  120 

Figure  52  C  language  definitions  of  software  module  ids.  These  appear  in  column  2  of  the  msg.trace  file. 


♦define  GEN.MSG  0 
♦define  RELAY_MSG  1 
♦define  RCV_MSG  2 

Figure  53  C  language  definitions  of  mesuge  events.  These  event  ids  appear  in  column  3  of  the  msg.trace  file. 
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♦define  BROADCAST.MSG  1 
♦define  LOCAL_MSG  0 
♦define  t'r2PT_MSG  2 

Figure  S4  C  language  definitioas  of  message  types.  These  types  appear  in  column  3  of  the  tnsg.trace  6le. 


10.1.7  Requirements  Thiceability 
TBD 

10.1.8  Notes 
None. 

10.1.9  Revisions  to  Section  10.1 
None. 

10.2  Software  Design  for  the  Link  Controller  (LC)  CSCl 

The  software  design  for  the  Link  Controller  is  covered  in  references  [7]  to  [10]. 

10.3  Software  Design  for  the  System  Controller  (SC)  CSCI 

10.3.1  Scope 

10.3.1.1  Identification 

Section  10. 1  covers  the  software  design  for  the  System  Controller  (SC)  CSCI.  which  is  a  compo¬ 
nent  of  the  Network  Frequency  Selection  Experiment  (N^E)  system. 

103.1.2  System  Overview 

See  section  5.1.2  on  page  13. 

103.13  Subsection  Overview 

Section  10.1  describes  the  design  of  die  SC  CSCI. 

1033  Referenced  Documents 
See  Section  3. 
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1033  Preliminary  Design 


1033.1  SC  Overview 

10.33.1.1  SC  Architecture 

Figure  S5  shows  the  architecture  of  the  System  Controller.  It  consists  of  three  CSCs:  Archiver, 
Monitor,  and  SC  Startup.  It  contains  an  RS232  interface  for  connecting  to  the  Link  Controller  hardvme 
(M333NRL)  and  an  ethemet  port  for  connecting  to  the  two  CPU  boards  used  by  the  Network  Controller, 
i.e.,  NC_RT  and  NC.NRT.  The  NFSE  System  operator  has  access  to  all  of  the  features  normally  available 
to  a  user  of  a  Sun  Wwlcstation.  The  System  Controller  includes  a  hard  disk  for  storing  archived  data,  NFSE 
System  software,  and  NFSE  System  input  hies.  The  Monitor  provides  tools  for  monitoring  and  controlling 
die  NFSE  System.  The  operator  uses  tools  that  these  CSCs  and  the  Sun  Unix  environment  provide  in  order 
to  start  maintain,  and  stop  the  NFSE  System. 


SC  Startup 


Sun  4 


Archiver 


Monitor 


System 

Controller 

(SO 


osl 


Serial  Port  PEthemet  Port! 


toM333NRL  toLANCNTR 


Figure  SS  System  Controller  (SC)  architecture  dwwing  CSCs,  key  interfeces,  and  the  target  hardware. 


10.333  SC  Design  Description 

The  SC  CSCI  is  decomposed  into  several  computer  software  components  (CSC),  udiich  are 
described  in  this  subsection. 

10333.1  SC  Startup  (SC_SU)  CSC 

The  SC  Startiq)  CSC  is  software  used  by  the  operator  to  start  the  NFSE  System. 
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The  SC_SU  supports  all  of  the  requirements  specified  in  section  S.3.2.1. 


10.3J.2^  Arehiver  (SC_ARC)  CSC 

The  Archiver  CSC  writes  compressed  copies  of  the  input  and  output  data  files  and  names  these 
files  by  concatenating  the  name  of  the  host  SC  Sun  and  the  time  that  the  data  was  written. 

The  SC_ARC  suf^rts  all  of  the  requirements  specified  in  section  5.3.2. 1. 

1C.3J.2J  Monitor  (SC_MON)  CSC 

The  Monitor  CSC  provides  a  view  of  the  state  of  the  operating  NFSE  System.  This  is  used  to  assist 
the  operator  in  diagnosing  system  failures  and  to  aid  in  assessing  the  overall  “health”  of  the  system. 

The  SC_MON  supports  all  of  the  requirements  specified  in  section  S.3.2.1. 

10.3.4  Detailed  Desig.1 

10.3.4.1  SC  Startup  (SC.SU)  CSC 

The  SC  Startup  CSC  is  made  up  of  the  NFSE  Startup  Scripts  (NFSE.StartupScripts). 

10.3.4.1.1  NFSE  Startup  Scripts  (NFSE.StartupScripts) 

10.3.4.1.1.1  NFSE  Startup  Scripts  Design  Spedfication/Constraints 

The  NFSE.StartupScripts  perform  the  following  functions: 

•  Provide  windows  for  communicating  to  NC_RT,  NC_NRT,  and  M333NRL.  and  SC  hardware. 

•  Provide  initializations  for  the  NC_RT,  NC_NRT,  and  M333NRL  VME  boards. 

There  are  five  startup  scripts.  The  script  for  creating  the  four  windows  mentioned  above  is  called 
SC_windows.sctipt  Each  of  the  four  windows  has  a  startup  script  associated  with  it.  The  names  of  these 
scripts  are  obtain^  by  concatenating  the  window  title  and  “.script”.  Thus,  the  four  scripts  are:  SC.script, 
NC_RT.sctipt,  NC_NRT.script,  and  M333NRL.script  The  following  sections  describe  the  functions  pro¬ 
vided  by  these  startup  scripts. 

10.3.4.1.1.1.1  SC_windows.script 

Figure  17  shows  the  four  windows  that  are  created.  Their  names  identify  the  hardware  to  which 
these  windows  interface.  IVro  of  the  windows  are  used  to  provide  access  to  the  MVME13SA  CPU  boards 
used  by  the  Network  Controller.  These  boards  are  the  NC_RT  and  NC_NRT,  and  they  reside  in  the  VME 
chgiMis  of  the  Black  Link  Controller.  The  connections  are  accomplished  by  running  the  Unix  rlogin  pro¬ 
gram  from  the  windows  labeled  NC_RT  and  NC_NRT.  One  window  is  connected  to  die  console  port  of  the 
MVME333  board  named  M333NRL,  whidi  also  resides  in  the  VME  chassis  of  the  BLC.  This  connection 
is  obtained  by  miming  the  Unix  tip  inogram  from  the  M333NRL  window.  The  fourth  wiiKiow,  called  SC, 
is  used  for  tunning  the  Unix  shell  on  the  System  Controller.  The  operator  may  open  and  close  other  win- 
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dows,  as  desired.  This  might  be  done  to  edit  input  hies,  examine  ouqnit  hies,  view  source  code.  etc.  There 
may  be  other  windows  on  the  screen  also. 


10.3.4.1.1.1J  SC.script 

The  functions  of  SCscript  are  as  follows: 

•  TBD 

10.3.4.1.1^  NC_RT.script 

The  functions  of  the  NC.RTsaipt  are  as  follows: 

•  TBD 

10.3.4.1.1.3  NC_NRT.script 

The  functions  of  NC_NRT.script  are  as  follows: 

•  TBD 

IOJ.4.1.1.4  M333NRL.script 

The  functions  of  M333NRL.script  are  as  follows: 

•  TBD 

IOJ.4.2  Areh!ver(SC_ARC)CSC 

10.3.4.2.1  Archiver  Design  Specification/Constraints 

The  Archiver  shall  provide  software  to  facilitate  the  writing  of  any  hies  ending  in  “.out",  “inp”,  or 
“.trace”  to  magnetic  tqx  for  later  analysis. 

IOJ.4.2.2  Archiver  Design 

A  Unix  shell  script  controls  the  archiving  of  all  test  results.  This  soipt  is  to  be  executed  by  each 
site's  operator  by  typing  the  “save”  conunand  into  the  NC.NRT  window  at  the  end  of  each  test  tun.  All 
hies  in  the  current  working  (hrectory  ending  in  “iiq)”,  “trace”,  and  “out”  are  compressed  and  written  in 
Unix  tar  format  to  hie  in  the  directory  ThrJ'n=SE_r^ults.  The  name  given  to  the  coiopressed  hie  is  formed 
by  concatenating  the  name  of  the  unix  host  at  the  site  with  the  current  date  and  time,  e.g.  ath- 
ena.900927.072213  is  the  hie  archived  at  host  “athena”  on  9/27/90  at  time  Oocal  host  time)  07:22:13. 

10 J.4 J  Monitor  (SC.MON)  CSC 

10JA4  Monitor  Design 
TBD 
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10.3J  SC  Data 


TBD 

10.3.6  SC  Data  Files 
TBD 

10J.7  Requirements  Ihiceability 
TBD 

10.3.8  Notes. 

10.3.8.1  Refinements  to  the  Frequency  Selection  Metric 

Duiing  the  NC  CSCI  evaluation  (see  section  14.4. 1. 1).  the  importance  of  refining  the  frequency 
selection  metric  to  consider  also  the  number  of  links  in  networks  with  similar  backbones  became  apparent. 
The  initial  metric  definition  (Metric  A)  only  takes  into  account  the  size  of  the  required  backbone.  An 
improved  metric  (Metric  B)  introduces  the  number  of  links,  as  an  additional  measure  of  overall  netwmk 
connectivity  to  be  considered  as  part  of  the  metric  evaluation. 

10.3.8.1.1  Frequen^r  Selection  Metric  B 

Metric  B  adds  the  additional  field  "Number  of  Unconnected  Links  (NUL)”  as  the  third  most 
inqxtrtant  consideration  in  selecting  the  best  operating  frequency.  NUL  is  N*(N-l)/2  minus  the  known 
number  of  bidirectional  links  in  the  network.  The  expanded  metric  is  shown  in  figure 
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10.3.9  Revisions  to  Section  10.3 


None. 


113 


11.  INTERFACE  DESIGN  DOCUMENT 

11.1  Scope 

11.1.1  Identification 

This  section  serves  a  the  Interface  Design  Document  (IDD)  for  the  NFSE  system. 

11.1.2  System  Overview 

See  section  S.12  on  page  13. 

11.13  Section  Overview 

Section  1 1  specifies  the  detailed  design  for  the  interfaces  between  CSCIs  of  the  NFSE  system. 

11.2  Referenced  Documents 

See  Section  3. 

113  Interface  Design 
113.1  Interface  Diagrams 


Figure  57  identifies  the  interfaces  between  the  CSCIs  of  the  NFSE  System.  Each  of  these  inter¬ 
faces  is  described  in  subsequent  sections. 
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11.3J!  NC/LC  Interface  (IF_NC_LC) 

The  following  procedure  calls  are  implemented  by  the  NDDS  and  used  by  the  NC  to  access  LX? 
resources.  Also,  the  interface  facilitates  the  delivery  of  data  (i.e..  checksum  blocks)  and  status  information 
from  the  LC  to  the  NC. 

•  PROCEDURE  allocate_receivc_stiing(ni(Lrid.crror_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  rid:  Integer  id  number  of  the  receive  string  being  allocated. 

«  enor_code:  Integer  value  letumed  where  0  means  no  error  and  >0  indicates  id  of  NC  to 
which  rcvr  is  already  allocated. 

-  Called  by  NSMA  at  activation  time. 

•  Allocates  a  receive  string  to  an  NC. 

•  PROCEDURE  deallocate_receive_string(nidjid,erTor_codc) 

>»  nid:  Integer  id  number  of  the  requesting  nc. 

»>  rid:  Integer  id  number  of  the  receive  string  being  deallocated. 

«  :  Integer  value  returned  where  0  means  no  error  and  >0  indicates  id  of  another  NC  to  which 

rcvr  is  allocated. 

No  calls  are  made  to  this  NDDS  procedure  in  the  present  NC  implementation.  It  will  have  utility 
when  multiple  NC’s  share  receive  string  resources. 

•  Deallocates  a  receive  string  from  an  NC 

•  PROCEDURE  allocate_transmit_string(T>i(l,xid,enor_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string  being  allocated. 

«  error.code:  Integer  value  returned  whoe  0  means  no  error  and  >0  indicates  id  of  NC  to 
which  xmtr  is  already  allocated. 

-  Called  by  NSMA  at  activation  time. 

-  Allocates  a  transmit  string  to  an  NC 

•  PROCEDURE  deallocate_transmit_string(nid.Jud,error_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string  being  deallocated. 

«  error_code:  Integer  value  returned  where  0  means  no  error  and  >0  indicates  id  of  another 
NC  to  which  xmtr  is  allocated. 

-  No  calls  are  made  to  this  NDDS  procedure  in  the  present  NC  implementation.  It  will  have  utility 
when  multifde  NC’s  share  transmit  string  resources. 

•  Deallocates  a  transmit  string  from  an  NC. 

•  PROCEDURE  send_packet(nidjud,packct,enDr_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string  that  the  seod_packet  request  is  for. 

>»  packet:  Bitvector  containing  data  for  an  entire  packet 

«  error.code:  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

inLC) 

•  Called  by  TBMA  when  a  transmission  packet  is  ready  to  send. 

•  Hands  an  entire  packet  to  a  transmission  string. 
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•  PROCEDURE  prq>arc_to_sciid_ncxt_slot(nid.xid.eiTor_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  xid:  Integer  id  number  of  die  transmit  string. 

«  enor_code:  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

inLC) 

-  Called  by  ES  (scheduled  by  CAA)  prior  i-200  ms)  to  the  next  transmission  slot. 

•  Informs  the  LC  Timing  Controller  to  raise  the  modem’s  RTS  line  high  at  the  next  RTS  time. 

•  PROCEDURE  set_slot_timiog(nidjdd,t_first_rts,sIot_duration,ettor_code) 

»>  nid:  Integer  id  number  of  the  reque^ng  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string. 

»>  t_first_rts:  Real  number  giving  the  second  of  the  day  when  the  first  RTS  event  should 
occur. 

»>  slot.duratioo:  Real  number  giving  the  duration  of  a  transmission  slot  in  seconds. 

«  error_code:  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

inLC) 

.  Called  by  NSMA  at  initialization  time. 

-  At  initialization  time,  gives  the  LC  Timing  Controller  information  required  for  the  computation 
of  RTS  and  tcvr  charmel  switching  event  times. 

•  PROCEDURE  set_xmtT_packetJength(nidjtidJength,error_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string. 

»>  length:  Integer  spediying  the  transmission  packet  length  in  bits  (without  checksum  bits 
added). 

«  etior_code:  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

inLC) 

•  Called  by  NSMA  at  initialization  time. 

At  initialization  time,  gives  packet  length  information  to  the  Xmit  Error  Detection  Algorithm. 

•  PROCEDURE  set_xmtr_nb_channel(nidjtid,chan_num,erTor_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string. 

»>  chan.num:  Integer  code  identifying  a  narrowband  transmission  channel. 

«  enorjcode:  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  -> 

error  inLC) 

-  Called  by  NSMA  at  initialization  time. 

-  At  initialization  time,  tells  LC  which  channel  to  switch  the  transmitter  to. 

•  PROCEDURE  set_xmtr_inforate(nid,rid,bps,etror_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

>»  xid:  Integer  id  numba  of  the  transmit  string. 

>»  bps:  Integer  giving  tiie  transmisrion  rate  in  bits  per  second. 

«  enoTjcode:  Integer  error  code  indicator  (0->  no  error,  >0->  error  in  NC/NDDS,  <0->  error 

inLC) 

•  Called  by  NSMA  at  initialization  time. 

•  At  initialization  tinm,  tells  LCaiiat  transmission  rate  to  set  for  the  transmit  side  of  the  modem 
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designated  by  XID.  • 

•  PROCEDURE  set_xnitrJnterleaver(nidjdd4ium_frames.crror_code) 

>»  nid:  Integer  id  number  of  the  requesting  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string. 

»>  num.frames:  Integer  specifying  the  number  of  20ms  modem  frames  for  the  interieaver 
depth. 

«  error_codc;  Integer  eiior  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

in  LC) 

•  Called  by  NSMA  at  initialization  time. 

-  At  initialization  time,  tells  LC  how  to  set  the  modem's  transmit  side  interleaver  depth. 

•  PROCEDURE  set_xmtr_powcr(nid,xid,watts,etror_code) 

»>  .  nid:  Integer  id  number  of  the  requestii^  NC. 

»>  xid:  Integer  id  number  of  the  transmit  string. 

»>  watts:  Integer  specifying  the  transmitter  power  level  in  watts. 

«  error_code:  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

inLC) 

At  initialization  time,  tells  LC  how  to  set  xmtr  power  level. 

•  PROCEDURE  set_rcvr_packetjength(oidjid,length,enor_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  rid:  Integer  id  number  of  the  receive  string. 

»>  length:  Integer  specifying  the  transmission  packet  length  in  bits  (without  checksum  bits 
added). 

«  error.code:  integer  error  code  indicator  (0->  no  error,  >0->  error  in  NC/NDDS,  <0->  error 

inLC) 

■  Called  by  NSMA  at  initialization  time. 

-  At  initialization  time,  gives  packet  length  information  to  the  Rev  Eiror  Detection  Algorithm 
and  the  modem’s  receive  side. 

•  PROCEDURE  set_rcvr_nb_channel(nid4id.chan_num,error_codc) 

»>  nid:  Integer  id  number  of  the  requesting  NC 
>»  rid:  Integer  id  number  of  die  receiver  being  allocated. 

»>  chan_num:  Integer  code  identifying  a  narrowband  transmission  channel. 

«  error_codc:  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

in  LC) 

•  Called  by  RSA  prior  (~  3(X)  ms)  to  the  slot  for  which  the  receiver  must  be  retuned. 

•  Tells  LC  Timing  Controller  which  narrowband  channel  to  set  the  receive  to  at  the  next  receiver 
tuning  time. 

•  PROCEDURE  set_rcvr Jnforate(nid4d,bps,error_code) 

»>  nid:  Integer  id  number  of  the  reqiwsting  NC. 

»>  rid:  Integer  id  number  of  die  reodva  being  allocated. 

»>  bps:  Integer  giving  the  transmission  rate  in  bits  per  second. 

«  ein»_code:  Integer  error  code  indicate  (0  ->  no  error,  >0  ■>  error  in  NC/NDDS,  <0  ->  error 

inLC) 
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Called  by  NSMA  at  initialization  time. 

At  initialization  time,  tells  LC  what  transmission  rate  to  set  for  the  receive  side  of  the  modem 
designated  by  RID. 

•  PROCEDURE  set_rcvr_interleaver(nicLrid.num_frames.error_code) 

»>  Did:  Integer  id  number  of  the  requesting  NC. 

»>  rid:  Integer  id  number  of  the  receiver  being  allocated. 

»>  num.frames:  Integer  specifying  the  number  of  20ms  modem  frames  for  the  interleaver 

depth. 

«  error_code:  Integer  error  code  indicttor  (0  ->  no  error.  >0  *>  error  in  NC/NDDS.  <0  ->  error 

inLC) 

-  Called  by  NSMA  at  initialization  time. 

-  At  initialization  time,  tells  LC  how  to  set  the  modem’s  receive  side  interleaver  depth. 

•  PROCEDURE  read_signal_quality(nidjid.quality.efror_code) 

>»  nid;  Integer  id  number  of  the  requesting  NC. 

»>  rid;  Integer  id  number  of  the  receiver  being  allocated. 

«  quality;  Integer  value  that  quantifies  signal  quality. 

«  error_code ;  Integer  error  code  indicator  (0  •>  no  error.  >0  ->  error  in  NC/NDDS.  <0  ->  error 

inLC) 

Not  called  in  the  present  implementation.  NSMA  may  use  this  in  a  later  implementation. 
Respond  to  a  request  for  modem  generated  signal  quality  information. 

•  PROCEDURE  read_rcvr_nb_chaiuicl(nidjid.chan_num.etror_code) 

»>  nid:  Integer  id  number  of  the  requesting  NC. 

»>  rid:  Integer  id  number  of  die  receiver  being  allocated. 

«  chan_num:  Integer  code  identifying  a  narrowband  transmission  channel. 

«  error_code;  Integer  error  code  indicator  (0  ->  no  error,  >0  ->  error  in  NC/NDDS,  <0  ->  error 

in  LC) 

-  Called  by  RSA. 

Return  the  channel  setting  of  the  receiver  identified  by  RID. 

11.33  LC/LC  Interface  (IF_LC_LC) 

Information  is  exchanged  between  Link  Controllers  in  packets  that  fit  into  one  transmission  slot 
The  format  of  this  packet  is  described  below. 

1133.1  Link-Uvel  Packet  (LC^PKT) 

A  link-level  transmission  (LC.PKT)  is  organized  into  192-bit  blocks,  as  shown  in  figure  58.  Each 
block  consists  of  176  “data”  bits  followed  by  a  16-bit  checksum  (except  for  the  last  block  which  has  only 
an  8-bit  checksum)^  The  number  of  blocks  is  determined  by  the  duration  of  a  transmission  slot  and  by  the 
information  rate  of  the  transmitter. 


1.  Thft  finally  rhwrlrmin  nn  ih^  l««t  hlnrk  nwin  njifiKSMated  by  fanplementalion  details  relaliny  to  svncfarooizinf  to 
the  modem  used  in  the  UNT  demonstiatioii. 


Its 


11^.4  NC/NC  Interface  (1F_NC_NC) 


11.3.4.1  Synchronous  Messages 

11.3.4.1.1  Frame  1  Synchronous  Message  (SMSG.Fl) 

Figure  *59  shows  the  fonnat  of  synchronous  messages  sent  out  during  frame  1.  Note  that  the  hrst 
two  message  fields  vary  in  length  depending  on  the  ID  number  of  the  transmitting  node  and  the  number  of 
nodes  in  the  network.  The  formats  shown  in  Rgure  59  and  several  of  the  following  figures  are  for  a  seven- 
node  network  and  assume  node  i  (i  -  4)  is  transmitting.  If  the  description  of  particular  message  field  is  fol¬ 
lowed  by  “(UND”.  this  indicates  that  these  bits  are  not  used  by  the  NFSE  System. 


a 

JLX 


L.  I  i  I  LI  I  I  I  I  I  L  > 


I  I  I.  I  1.  i  i 


J  i-l.L 


Description  of  Field 

bits 

a.  Frame  1  ACK/NAK  for  PPA 

i-1 

b.  LQI  vector  for  node  i 

NB_SINGLE_LQI*N 

c.  Num.  slots  requested  (UNT) 

NB.SLOTS.REQUESTED 

d.  New  traffic  lim.  (requested) 

NB_TRAFHC_LIMIT_REQUESTED 

Msg.  size  (bits)  NB_SINGLE_LQI*N+i.l+NB_SLOTS_REQUESTED 

+NB_TRAFnC_LIMIT_REQUESTED 

Figure  59  Concrol  message  for  frame  1  transmission  from  Node  i  (is4,  Nx7) 
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11.3.4.1.2  Frame  2  Synchronous  Messages  (SMSG_F2) 

The  format  of  the  transmission  buffer  for  the  frame  2  transmission  differs  depending  on  whether 
the  transmitting  node  is  a  clusterhead  or  a  non-clusterhead.  The  simpler  format  is  the  one  used  by  cluster- 
heads;  it  is  shown  in  Figure  60.  Figure  61  shows  the  corresponding  format  for  a  non-clusterhead  node. 


i  1 1 

b 

1  1  1  1  1  L 

c 

1  1  i  i 

1  1  1  1  1 

d 

1  1  1  1  1  1  1  1  1 

1  1  1  1  1 

n 

Description  of  Field 


bits 


a.  Farae2ACK/NAKforPPA 

b.  RB-neighbors 

c.  ID  of  own  clusterhead 

d.  Cluster  schedule  (UNT) 


N-i 


N 

NB_NODE_ID 

nb_slots_allcx:ated*n 


Msg.  size  (bits) 


2N+NB_SLOTS_ALLCX:ATED*N-i-KNB_NODE_ID 


Figure  60  Control  message  for  frame  2  transmission  from  clustertaead  Node  i  (i=4.  N=7) 
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f 

U-i-l 

4  1  1  I-t. 
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44444 
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I  I  I  1  »  I 


b 

J-L 


additional  schedule  reports 


Description  of  Field 


bits 


a.  Frame2ACK/NAKforPPA 

b.  RB-neighbors 

c.  ID  of  own  clusterhead 

d.  Num.  schedules  reported  (R)  (UNT) 

e.  Schedule  ID  (UNT) 

f.  Schedule  length  (UNT) 

g.  Pos.  in  schedule  (UNT) 

h.  Slots  received  (UNT) 


N-i 


N 

NB_NODE_ID 

NB_NUM_SCHEDS_REPORTED 

NB_NODE_ID 

NB_NODEJD+NB_SLOTS_ALLOCATED 

nb_node_id+nb_slots_allcx:ated 

NB_SLOTS_  ALLOCATED 


Msg.  size  (bits)  2N-i+NB_NODE_ID+NB_NUM_SCHEDS_REPORIED 

■f3R(NB_NODE_ID+NB_SLOTS_ALLOCATED) 


Figure  61  Cootiol  message  for  {rame  2  transmissioD  hom  iK>D<lusteitaead  Node  i  (i>4.  N«7) 
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11.3.4.  U  Frame  3  Synchronous  Messages  (SMSG_F3_CH)  and  (SMSG_F3_NON_CH) 

As  was  the  case  for  frame  3.  the  packet  formats  for  frame  3  differ  for  clusterheads  and  ncm-cluster- 
heads.  Figure  62  shows  the  format  used  by  the  former,  and  Figure  63  shows  the  format  used  by  the  laner. 


Description  of  Field 


bits 


a.  Node  status  NB_STATUS 

0  s  Qusterhead 

1  s  Terminator  Node 

2  s  Boundary  Node 

3  s  Gateway 

Msg.  size  (bits)  NB_STATUS 


Figure  62  Control  Message  for  frame  3  transmission  from  a  ciusterbead. 


Description  of  Field 

a.  Node  status 

b.  Num.  schedules  rpt.  (R)  (UND 

c.  Schedule  ID  (UNT) 

d.  Schedule  length  (UND 

e.  Pos.  in  schedule  (UND 

f.  Slots  received  (UND 


bits 

NB.STATUS 

NB_NUM_SCHEDS_REPORTED 

NB_NODE_ID 

NB.NODE.ID+NB.SLOTS.ALLOCATED 

NB.NODE.ID+NB.SLOTS.ALLCXTATED 

nb_slots_allcx:ated 


Additional  schedules 


Msg.  size  (bits)  NB_STATUS+NB_NUM_SCHEDS_REP0R1ED 

+3R(NB_NODEJD+NB_SLOTS_ALL(X:aTED) 


Figure  63  Control  message  for  hame  3  transmission  from  a  non-chisterfaead 
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11.3.4.2  Asynchronous  Messages 

In  the  internal  network,  all  asynchronous  data  traffic  is  sent  in  one  of  three  kinds  of  messages; 
point-to-point,  broadcast,  or  local  messages.  A  fourth  type  of  message  is  the  null  message,  which  is  used  to 
indicate  that  no  more  data  follows  in  the  slot  This  section  shows  the  headers  for  these  messages.  Data 
immediately  follows  each  header,  except,  of  course,.in  the  case  of  null  messages  where  no  data  is  present. 


11.3.4.2.1  Point'to- Point  Asynchronous  Message  (AMSG_P2P) 


Figure  64  shows  the 


point-to-point  message  header. 


E 

NC  Ftor» 

1  1  1  ■ 

1  1  1  _l 

length 

1  1  1  1  1  1 

1  1  1 

I 

pri 

source 

i 

L- 

a 

#■  ■ 

■■  I.  1  1 

— 1 

desC  1 

relay  1 
‘  ‘  ■  1  1 

Description  of  Field 


bits 


10  -  Point-to-Point  Message  TVpe 

NC_PORT# 

length  of  msg  (bits) 

r  -  reliability 

pri  -  priority 

source 

seq  #  -  sequence  # 
dest  -  destination 
relay 

Figure  64  Point-to-point  message  header. 


NB_MSG_TYPE 

NB_NC_PORT 

NB.LENGTH 

NB.RELIABILITY 

NB_PRI 

NB_N0DE_1D 

NB.SEQ 

NB.NODEJD 

NB_NODE_ID 
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11.3.4.2^  Broadcast  Asynchronous  Message  (AMSG_BRCST) 


Figure  65  shows  the  broadcast  message  header 


i 

NCPort 

till 

length 

1  1  1  1  1  1  1  1  »  1  1  1  1 

r 

pri 

-  1— 

source 

-i  i  >  > 

j-  1  1 

s 

u 

a 

« 

LI,  1  1  , 

Description  of  Field  bits 


01  -  Broadcast  Message  lype 

NC.PORT# 

length  of.msg  (bits) 

r  -  reliability 

pri  -  priority 

source 

seq  # -  sequence  # 
sp  -  spare 


NB_MSG_TYPE 

NB_NC_PORT 

NB.LENGTH 

NB_RELIABILITY 

NB_PRI 

NB.NODEJD 

NB_SEQ 

fill  to  nearest  8-bit  boundary 


F’guie  6S  Broadcast  message  header 


11.3.4.23  Local  Asynchronous  Message  (AMSG_LOCAL) 
Hgure  66  shows  the  Local  Message  header. 


0 

)  NCPort 
-.1111 

length 

IIIII1I1<1I<< 

■  “T" 

Description  of  (Held 


bits 


00  -  Local  Message  Type 
NC.PORT# 
lengdt  of  msg  (bits) 
r  -  reliability 
sp-spare 


NB_MSG_TYPE 
NB_NC_PORT 
NB.LENGTH 
NB.REUABIUTY 
All  to  nearest  8-bit  boundary 


Figure  66  Local  message  header 


113.4.2.4  Null  Asynchronous  Message  (AMSG_NULL) 
Figure  67  shows  the  Null  Message  header. 
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Description  of  Field 
11  -  Null  Message  IVpe 


bits 


11  - 


NB_MSG_TYPE 

Figure  67  Null  message  header 

11.3^  1F_SC_NC 

See  section  9.3.S. 

11.3.6  IF_SC_LC 
See  section  9.3.4. 

11.3.7  IF_OP_SC 
See  section  9.3.3. 

11.4  Notes 

None 

11.5  Revisions  for  Section  11 

None. 
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12.  NFSE  IN-LAB  TEST  PLAN 


12.1  Scope 

12.1.1  Identification 

This  section  provides  the  equivaleiu  of  a  Software  Test  Han  (STP)  document  for  the  NFSE  Sys¬ 
tem. 

12.1.2  System  Overview 

See  section  S.1.2  on  page  13. 

1Z13  Section  Overview 

This  Software  Test  Plan  describes  the  formal  qualification  test  plans  for  all  of  the  CSCIs  that  makp. 
up  the  NFSE  System.  The  STP  identifies  the  software  test  environment  resources  required  for  formal  qual¬ 
ification  testing  (FQT)  and  provides  schedules  for  FQT  activities.  In  addition,  the  STP  identifies  the  indi¬ 
vidual  tests  that  shall  be  performed  during  FQT. 

12J  Referenced  Documents 
See  section  3. 

123  NFSE  In-Lab  Test  Environment 

This  subsection  identifies  and  describes  the  plans  for  implementing  and  controlling  the  resources 
(software,  firmware,  and  hardware)  necessary  to  perform  formal  qualification  testing.  Three  test  facilities 
will  be  used  for  formal  qualification  testing.  They  are  identified  as  the  Distributed  Simulation  and  Proto¬ 
typing  Testbed  (DSFT),  the  Realtime  Testbed  (RTT),  and  the  Ibrget  Node  Testbed. 

Distributed  Simulation  and  Prototyping  Testbed  (DSPT)  -  The  DSPT  is  software  that  is  used  to 
simulate  and  prototype  radio  communication  networks  and  their  protocols.  The  DSPT  software  is  written 
in  C-H-  and  provides  a  library  of  software  objects  that  can  be  used  to  construct  models  of  communication 
systems.  For  example,  the  library  contains  objects  to  model  ships,  aircraft,  satellites,  communication  sta¬ 
tions,  transmitters,  receivers,  and  modems.  Simulation  channel  models  are  available  for  HF  groundwave 
and  Une-of-Sight  (LOS)  channels.  The  DSFT  is  based  on  the  commercially  available  simulation  package 
Sim-H-.  This  package  provides  time  synchronization  for  distributed,  as  well  as  sequential  simulations.  All 
of  the  network  control  software  for  NRL’s  UNT  {xoject  was  tested  using  the  DSPT,  and  a  simulation  model 
of  the  Link  Conirolla  used  in  the  UNT  tests  is  available. 
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Realtime  Testbed  (RTT)  -  The  RTT  consists  of  the  hardware  needed  to  perform  back-to- 
back.  realtime  tests  of  two  NFSE  System  nodes.  Table  28  shows  the  hardware  required  fw  the 
RTT. 


Table  28:  Hardware  Items  for  the  Realtime  Testbed 


Item 

Description 

Qty. 

MVME945B-1 

VME  Benchtop  Enclosures 

2 

MVME135A 

CPU  (4  Mbyte  DRAM) 

4 

MVME224A-1 

Memory  (4  Mbyte  DRAM) 

2 

ENP-IOL 

Ethernet  Controllers 

2 

Sun  Sparcstation 

Workstation 

1 

Target-Node  Testbed  (TNT)  -  The  TNT  consists  of  the  target  hardware  and  non-develop¬ 
ment  software  for  two  complete  NFSE  System  nodes  including  fiill  transmit  and  receive  strings. 
The  two  nodes  shall  be  tested  back-to-back  with  connectivity  achieved  through  RF  linkage. 

12.3.1  Software  Items 

The  following  software  items  a.'e  required  to  support  the  formal  qualification  testing  activ¬ 
ities. 

•  Distributed  Simulation  and  Prototyping  Testbed  software. 

•  Sim-H-  simulation  library  and  runtime  system. 

•  V  xWorks  software  development  environment,  including  target  operating  system  software. 

•  C-H-  compiler. 

12.3.1.1  DSPT  Software 

The  purpose  of  this  software  is  to  facilitate  the  construction  of  a  simulation  model  of  the 
NFSE  System.  The  DSPT  will  be  used  primarily  for  testing  the  logical  correctness  of  the  algo¬ 
rithms  used  to  implement  the  Network  Frequency  Selection  Service  (NFSS)  and  the  Internal  Net¬ 
work  Capability  (IN_CAP). 

12J.1.2  Sim-H- 

The  DSFT  is  built  on  top  of  the  commercial  simulation  package  Sim-H-.  Simulation  mod¬ 
els  written  in  Sim-H  will  be  executed  on  NRL  code  5521’$  computer  workstations. 

12J.1.3  VxWorks 

Ihis  software  provides  the  cross-development  tools  and  target  operating  system  needed  to 
develop  target  software  on  Sun  workstations  and  then  move  it  to  the  target  system  and  test  it 
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12.3.1.4  €++ Compiler 


The  conqjiler  of  choice  is  the  Object  Center  compiler  from  Center  Line. 

1232  Hardware  and  Firmware  Items 

A  Sun  SparcStation  is  required  for  simulation  with  the  DSFT.  The  target  node  hardware,  as  ^)eci- 
lied  in  table  28  is  required  to  support  the  testing  performed  using  the  RTT. 

Firmware  consists  of  bootroms  on  the  various  boards  of  the  VME  system.  Bootroms  for  the 
MV13S  boards  will  be  supplied  by  Wind  Rivers  Systems  as  part  of  the  VxWorits  package.  Initially, 
bootroms  for  the  MVME333  boards  will  be  obtained  from  the  UNT  Link  Controller  bootrmns  used  by 
NRL. 

1233  Proprietary  Nature  and  Government  Rights 

NRL  has  purchased  the  right  to  use  SinH~»-  and  VxWorks  in  the  development  and  in-lab  testing  of 
the  NFSE  System  software.  Sim-H-  will  not  become  a  part  of  the  target  system.  Depending  on  the  number 
of  target  sites,  some  additional  costs  may  be  required  for  the  use  of  VxWorks  in  the  target  system. 

12.3.4  Installation,  Testing,  and  Control 

This  subsection  describes  plans  for  controlling  and  maintaining  each  item  of  the  software  test  envi¬ 
ronment 

123.4.1  DSPT  Maintenance 

Any  maintenance  and  enhancements  required  of  the  DSFT  are  the  primary  responsibility  of  NRL 
Code  5521. 


12.3.4.2  Sim-f-i- Maintenance 

NRL  will  arrange  for  Jade  Simulations  Corporation  to  supply  continued  maintenance  on  its  SittH-t- 

product 

123.4.3  VxWorks  Maintenance 

NRL  will  arrange  for  continued  maintenance  of  die  VxWorks  system  by  Wind  Rivers  Systems  for 
the  duration  of  the  NFSE  {xoject 

123.4.4  Workstation  Maintenance 

NRL  has  formal  agreements  for  the  maintenance  of  Code  5521’$  workstations. 

123.43  Ikrget  Hardware  Maintenance 


12.3.4.6  MVME135  Bootrom  Maintenance 

Wind  Rivers  Systems  shall  provide  and  maintain  this  hrmware  as  part  of  its  VxWorks 
maintenance  agreement  with  NRL. 

12.3.4.7  MVME333  Bootrom  Maintenance 
NRL  Code  S521  shall  maintain  this  firmware. 

123.4.8  Support  Hardware  Maintenance 
To  be  determined  on  a  case-by-case  basis. 

12.4  Formal  Qualification  Test  Identification 

12.4.1  NFSE  System 

The  NFSE  System  CSCIs  shall  be  formally  tested  in  the  following  combinations;  NC.  NC/ 
LC,  SC/NC,  and  SC/NC/LC. 

12.4.1.1  General  Test  Requirements 

Each  formal  qualification  test  shall  meet  the  followii^  general  test  reqturements; 

a.  Hiere  shall  be  a  statement  of  the  purpose  of  the  test;  that  is,  what  is  to  be  tested. 

b.  Test  iiq)uts,  version  numbers  for  each  software  item  under  test,  and  test  results,  shall  all 
be  archived. 

c.  Test  conclusions  shall  be  reported. 

12.4.1.2  Test  Classes 

Tests  are  broken  up  into  four  classes:  algorithm  tests,  timing  tests,  start/stop  tests,  and  inte¬ 
gration  tests. 

12.4.1.2.1  Algorithm  Tests 

These  tests  are  aimed  at  verification  and  validation  of  the  system  design  requirements. 
That  is,  these  tests  attempt  to  answer  the  following  questions;  Does  the  system  Uiat  was  imple¬ 
mented  satisfy  the  system  requirements  (verification);  and  does  the  system  do  «4iat  the  user 
intends  it  to  do  (validation)? 
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12.4.1.2^  Hilling  and  Load  Tests 

These  tests  are  designed  to  see  if  the  NFSE  System  software  can  satisfy  its  realtime  requirements 
and  work  within  its  allocated  resources.  The  main  measures  are  procedure  execution  times  and  memory 
requirements. 

12.4.1.23  Node  Start/Stop/Start  Tests 

One  of  the  lessons  learned  from  the  UNT  tests  is  that  one  can  expect  a  high  occuirence  of  starting 
and  stopping  of  nodes  in  a  testbed  enviionmenL  This  class  of  test  is  intended  as  a  stress  test  of  the  NFSE 
System’s  ability  to  function  with  frequent  occurreiKes  of  nodes  stopping  and  restarting. 

12.4.1.2.4  Integration  Tests 

This  class  of  tests  focuses  on  how  well  the  SC.  NC,  LC.  and  RF  hardware  work  together  in  the  tar¬ 
get  system. 

12.4.13  Test  Levels 

Formal  tests  shall  be  performed  at  the  CSCI,  node,  or  system  level.  No  formal  test  shall  be  per¬ 
formed  below  the  CSCI  level.  However,  it  is  anticipated  that  considerable  informal  testing  will  be  done  at 
the  CSC/CSU  levels. 

12.4.1.4  Test  Definitions 

This  subsection  identifies  and  describes  each  test  to  be  performed  on  the  NFSE  System. 

12.4.1.4.1  7-Node  Simulation  (7NFSE) 

12.4.1.4.1.1  Test  Objective 

The  purpose  of  this  suite  of  tests  is  {Hovitte  the  following:  1)  to  check  out  whether  the  algorithms 
used  to  implement  the  system  result  in  a  system  that  meets  the  requirements  given  in  the  SSRS  (verifica¬ 
tion),  2)  to  validate  that  the  implemented  design  meets  the  intend^  system  needs  (validation),  and  3)  to 
provide  an  ardiive  of  the  performance  of  the  baseliitt  system.  The  test  performance  database  can  be  used, 
among  other  things,  as  a  benchmark  to  evaluate  alternative  metrics  that  the  NFSS  might  use  in  selecting 
the  *‘best”  operating  frequency. 

12.4.1.4.1.2  Special  Requirements 

These  tests  wfll  be  performed  on  a  Sun  workstation  or  equivalent 

12.4.1.4.13  Test  Level 

The  tests  will  be  performed  at  the  NFSE  System  level  using  simulated  Link  Controllers,  RF  trans- 
mitfreceive  strings,  and  communication  channds.  System  Mode  B  (without  the  optional  internal  network) 
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shall  be  tested.  Since  the  internal  network  will  not  be  used,  the  frequency  test  cycles  can  be  contig¬ 
uous,  i.e..  we  set  Tap  =  T^  (see  figure  3). 

12.4.1.4.1.4  Test  Type  or  Class 
This  is  an  algorithm  test. 

12.4.1.4.1.5  Qualification  Method 

These  tests  are  aimed  at  demonstrating  that  the  Network  Controller  can  provide  the  c^- 
bilities  specified  in  section  8.1.3. 

12.4.1.4.1.6  Type  of  Data  to  be  Recorded 

The  following  data  shall  be  saved  to  disk  for  each  test 

•  Version  identifiers  for  all  of  the  software  being  tested  and  for  key  support  software. 

•  All  input  and  output  data  files  (as  specified  in  section  10.1 .6). 

12.4.1.4.1.7  Assumptions  and  constraints 

The  tests  shall  employ  realistic  channel  simulation  models  that  include  the  effects  of  sto- 
diastic  noise  and  HF  groundwave  propagation  losses. 

12.4.1.4.2  Additional  Tests 
TBD 

12.4.1.5  TestSdiedule 

See  section  7.3.2. 

12.5  Data  Recording,  Reduction,  and  Analj^ 

This  subsection  describes  the  data  reduction  and  analysis  procedures  to  be  used  during  and 
following  the  tests  identified  in  this  STP.  This  subsection  documents  how  information  resulting 
firom  data  reduction  and  analysis  will  be  retained. 

Output  from  the  Network  FteqiKocy  Selection  Service  are  obtained  after  eadi  NFSS  fre¬ 
quency  test  cycle.  These  results  are  in  the  form  of  FrameMaker  “.mir  files.  When  viewed  using 
I^ameMaker  or  a  PostScript  reader,  each  page  of  results  appears  as  two  columns  by  four  rows  of 
grtqthics  panels.  Each  panel  di^lays  results  for  one  NFSS  fequency  test  cycle.  The  time-ordering 
of  results  is  firom  top  to  bottom  of  ftie  first  column  followed  by  the  same  ordering  in  die  second 
cniuniii  Each  panel  shows  the  fallowing  infrxmation:  an  NFSS  frequency  test  cycle  identifier,  the 
bidirectional  links  for  that  frequency  test  cycle,  the  value  of  the  metric  (in  hexadecimal  notadon), 
die  test  firequency  (in  MHz),  and  die  time  at  uliich  die  frequency  test  cycle  began  (in  simulated 
linnnin:sec.iii8). 
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When  using  the  optional  internal  network,  all  statistics  are  merged  into  a  single  staLout  file.  It  is 
necessary  to  pass  this  file  through  a  post-processor  filter  to  generate  separate  files  for  each  statistic  of  inter¬ 
est.  In  this  way  we  produce  the  following  additional  ouqxit  files  from  stat.out: 

load.out 

thniputout 

delay.out 

max.delay.out 

global_traffic_limiLout 

lcl_traffic_limitout 

These  are  in  “Cricket  Graph”  cotrqtatible  form  for  automated  post  analysis,  but  they  can  be  read 
manually  to  get  a  quick  look  at  network  performance.  The  interpretation  of  each  of  these  statistics  is  as  fol¬ 
lows. 

Load  Statistic 

Every  statistic  r  ^rting  period,  each  node  reports  the  average  rate  at  which  it  transmits  new  traffic 
since  the  last  reporting  period.  This  traffic  consists  of  eidier  broadcast  or  point-to-point  asynchronous  mes¬ 
sages.  The  load  includes  the  message  headers  added  by  the  Network  Controller,  which  is  40  bits  for  broad¬ 
cast  messages  and  48  bits  for  point-to-point  messages.  For  each  reporting  period,  the  file  load.out  contains 
one  line  of  output  consisting  of  the  following:  the  time  of  the  repon.  the  load  at  each  node,  and  the  sum  of 
the  loads  (i.e.,  the  load  on  the  entire  network). 

Throughput  Statistic 

Every  statistic  tepotting  period  each  node  reports  the  average  rate  at  which  simulated  user-data 
was  delivered  at  that  node  since  the  last  reporting  period.  The  “user”  data  consists  of  die  data-only  portion 
of  asynchronous  broadcast  or  point-to-point  messages;  that  is,  it  does  not  indude  the  message  herulers 
added  by  the  Network  Controller.  For  each  reporting  period,  the  file  thniputout  contains  one  line  of  output 
consisting  of  the  following:  the  time  of  the  report  the  throughput  at  each  node,  the  sum  of  the  node 
throughputs  (i.e.,  the  throughput  for  the  entire  network),  and  dw  “normalized  throughput”.  The  normalized 
througfvut  is  obtained  by  dividing  the  network  throughput  by  (A  -  /),  where  A  is  the  number  of  nodes 
%dve  during  the  reporting  interval.  If  the  load  consists  of  only  broadcast  traffic,  then  the  normalized 
throughput  should  be  nearly  equal  to  the  network  load,  since  each  broadcast  message  should  reach  (A  -J) 
nodes. 

Delay  Statistic 

Every  statistic  reporting  period,  each  node  reports  message  delay  statistics  for  all  the  broadcast 
and  point-to-point  messages  that  were  received  since  the  last  repwting  period.  This  statistic  includes  mini¬ 
mum,  average,  and  maximum  values  of  the  message  delays.  The  (telays  are  measured  firom  the  time  that 
the  message  is  first  transmitted  until  the  time  it  is  recdved  at  a  node.  This  is  accomplished  by  including  tiie 
initial  transmission  time  in  the  body  of  the  dummy  data.  For  each  reporting  period,  the  file  delay.out  con¬ 
tains  one  line  of  ouqnit  consisting  of  the  following:  the  time  of  the  report,  the  average  message  delay 
recorded  at  each  node,  and  the  average  message  delay  for  the  entire  networic. 

Maximum  Delay  Statistic 

Fw  each  rep(»ting  period,  the  file  max.delay.out  contains  one  line  of  output  consisting  of  the  fol¬ 
lowing:  the  time  of  the  report,  the  maximum  message  delay  receded  at  each  node  fiv  the  measurement 
period,  and  the  maximum  message  delay  for  the  entire  networic  over  that  same  period. 


13.  NF^EIN-LAB  TEST  DESCRIPTIONS 

13.1  Scope 

13.1.1  Identification 

This  Software  Test  Description  (STD)  describes  the  in-lab  tests  to  be  perftmned  on  the  Network 
Controller  CSCI  of  the  NFSE  System. 

13.12  System  Overview 

See  section  S.1.2  on  page  13. 

13.13  Section  Overview 

This  section  contains  the  test  cases  and  test  procedures  necessary  to  perform  formal  qualification 
testing  of  the  Network  Controller  CSCI,  which  is  the  major  componem  of  the  NFSE  System. 

133  Referenced  Documents 
See  references  [3]  and  (4]. 

133  Formal  Qualification  Test  Preparations 

133.1  7.Node  Simulation  (7NFSE) 

133.1.1  7-Node  Simulation  Schedule 
See  section  7.3.2. 


133.13  7-Node  Simulation  Pre-Test  Procedures 

133.13.1  Hardware  Preparation 

The  7NFSE  will  be  performed  on  a  Sun  Workstation  or  equivalent 

133.133  Software  Preparation 

In  preparation  for  simulation  testing  wifti  the  DSPT,  two  iiqxit  files  must  be  prepared,  namely,  cre- 
ate.dat  and  n£e  jiq>.  Examples  of  these  two  files  are  shown  in  figures  68  and  69,  respectively. 

Rle  create.datis  used  fm  specifying  the  simulation  scenario.  It  describes  die  communication  chan¬ 
nels,  the  idatfixms  (ships,  aircraft,  etc.),  and  parameters  that  contrtd  tiie  simulation  (duration  of  simulation, 
statistics  rqxtrting  period,  and  period  between  scenario  updates).  The  file  is  scanned  for  tiw  occurrence  of 
t4)ject  creation  commands  tint  contain  tin  keywords  cteate.chan,  create,  or  cteate_sys.  The  keyword  **cre- 
atejchan”  indicates  the  start  of  tin  description  of  a  communication  chanml  object;  tin  keyword  ‘'create” 
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signifies  the  start  of  the  description  of  a  platform  object:  and  “create.sys”  indicates  the  desaifMion  of  a 
system  object.  The  end  of  an  object’s  description  is  denoted  by  the  flag  99999.  Object  descriptions  may  be 
nested. 


TVvelve  chaimels  are  defined  in  figure  68.  Each  channel  is  an  object  of  type  hf_chan.  All  objects 
have  a  type  name  (hf.chan  in  this  case)  and  a  numerical  ittendfier.  which  consi^  of  a  zero-terminated  list 
of  numbm.  Thus,  in  the  example  there  are  twelve  channel  objects  of  type  hf_chan  with  identifiers  that 
range  fiom  1  to  12.  'The  second  line  of  the  create  hf.chan  entry  signifies  tte  median  channel  noise  level  in 
db  referenced  to  1  watt  In  the  example,  each  chaimel  has  the  same  median  imise  level  of  •  123  db.  The  final 
entry  in  the  description  of  the  hf_chan  objea  is  the  hf  frequency  of  this  chaimel.  The  frequency  is  used  by 
the  groundwave  propagation  loss  model  to  compute  the  propagation  attenuation. 

The  example  file  create.dat  dehnes  seven  platforms.  Each  platform  definition  begins  with  the  key¬ 
word  “create”.  All  platforms  are  of  type  “near_earth”  platform.  This  type  is  used  to  represent  fixed-sites, 
ships,  and  aircryt  The  platforms  have  numerical  identifiers  that  range  from  1  to  7.  Platforms  have  a  geo¬ 
graphic  position,  which  is  expressed  in  terms  of  longitude  (-180  (W)  to  180  (E)),  latitude  (-90  (S)  to  90 
(N)),  and  altitude  (0  to  100  km).  Since  some  platforms  are  mobile,  a  time  (given  in  seconds)  is  associatnl 
with  the  position  coordirates.  lime  0.0  corresponds  to  the  start  of  the  simulation.  There  are  one  or  more 
lines  of  the  form  “longitude  latimde  altitude  time”  included  in  each  platform  description.  These  lines  are 
preceded  by  a  line  containing  an  integer  that  specifies  the  number  of  positions  that  follow.  Platform  num¬ 
ber  7  is  an  example  of  a  mobile  platform;  the  other  plsuforms  are  stationary. 

Each  platform  contains  an  object  of  type  “logic_node”.  Logic_nodes  have  numerical  identifiers 
that  consist  of  two  integers  -  the  first  number  identifies  the  host  platform  (1  to  7)  and  the  second  identifies 
the  node  at  that  platform  (1).  Logic_nodes  contain  objects  of  types  “transmitter”,  “receiver”,  “scen_cont”, 
“UNT_PrLaycr2”,  and  “UNT_PrLayer3”.  The  last  three  object  types  are  used  to  represent  the  three  lowest 
inotocol  layers  of  the  communication  system  that  we  are  modeling. 

The  start  of  the  description  of  a  transmitter  begins  with  the  keyword  “transmitter”,  which  is  fol¬ 
lowed  by  a  numerical  identifier  of  the  form  “platform_number  node.number  transmitter.number  0”.  Sub¬ 
sequent  lines  in  the  description  ate:  (line  2)  channel.name  channel_number.  (line  3)  radiated  power 
(watts),  and  (line  4)  999999.  When  the  transmitter  objea  is  created,  it  will  initially  be  set  to  the  given 
chaimeLnumber. 

The  start  of  the  description  of  a  receiver  begins  widi  die  keyword  “receiver”,  which  is  followed  by 
a  numerical  identifier  of  the  form  “platform.number  node.number  receivcr_number  0”.  Subsequent  lines 
in  the  description  are:  (line  2)  channel_name  channeLnumber.  (line  3)  required  signal-to-noise  ratio  (db). 
(line  4)  receiver  noise  (db  relative  to  1  watt,  and  (line  5)  999999.  When  the  receiver  objea  is  created,  it 
will  initially  be  set  to  the  given  chaimeLnumber.  In  the  example,  each  receiver  is  assigimd  a  receiver  noise 
level  of  -123  db.  The  model  sets  the  noise  at  the  receiva  as  the  maximum  of  the  channel  noise  and  the 
receiver  noise.  In  the  example,  the  requited  signal-to-noise  level  of  34  db  is  meant  to  approximate  a  link 
that  is  90%  reliable  and  is  operating  at  2A00  bps. 

The  start  of  die  description  of  a  protocol  objea  that  models  piotocol_ltiyer_number  1  ({diysical 
layer)  begins  with  the  keyword  “scen_cont”,  which  is  foflowed  by  a  numerical  identifier  of  the  form  “plat- 
form_number  node_number  protocolJayer_number  0”.  Subsequea  lines  in  the  description  are:  (line  2)  0 
and  dine  3)  999999? 

Ihe  Stan  of  the  description  of  a  protocol  objea  that  models  protocol  Jayer.number  2  (data  link 
layer)  begins  with  the  keyw(»d  “UNT_PrLayei2”,  which  is  followed  by  a  numerical  identifier  of  the  fiirm 
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■‘platform.nuraber  node_number  proiocolJayer_number  0".  Subsequent  lines  in  the  description  are:  (line 
2)  0,  (line  3)  number  of  transmit  strings  (1),  (line  4)  number  of  receive  strings  (1),  and  Cine  S)  999999. 

The  start  of  the  description  of  a  protocol  object  that  models  i^tocoljayer.number  3  (network 
layer)  begins  with  the  keyword  “UNT_PrLayer3”.  which  is  followed  by  a  numerical  identifier  of  the  form 
“platform.number  node.number  protocol_layer_number  0”.  Subsequem  lines  in  the  description  are:  (line 
2)  0.  (line  3)  1,  and  (Une  4)  999999. 

The  start  of  the  description  of  a  system  object  that  models  the  simulator  begins  with  the  keywmd 
"system”,  which  is  followed  by  a  0.  Subsequent  lines  in  die  description  are:  (line  2)  simulation  duratitm 
(milliseconds),  (line  3)  statistics  reporting  period  (milliseconds),  (line  4)  scenario  update  period  (seconds), 
(line  5)  0,  (line  6)  0,  and  (line  7)  999999. 

create_chan  hf_chan  1  0 
-100.000000  db  (watts) 

10.680  MHz 
999999 

create_chan  hf_chan  2  0 
-115.000000  db  (watts) 

11.062  MHz 
999999 

create_chan  hf_chan  3  0 
-135.000000  db  (watts) 

12.030  MHz 
999999 

create_chan  hf_chan  4  0 
-125.000000  db  (watts) 

12.673  MHz 
999999 

create_chan  hf_chan  5  0 
-110.000000  db  (watts) 

13.238  MHz 
999999 

create_chan  hf_chan  6  0 
-125.000000  db  (watts) 

13.980  MHz 
999999 

create_chan  hf_chan  7  0 
-105.000000  db  (watts) 

14.695  MHz 
999999 

create_clian  hf_chan  8  0 
-135.000000  db  (watts) 

16.923  MHz 
999999 

create_chan  hf_chan  9  0 
-120.000000  db  (watts) 

16.954  MHz 
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999999 

create_chan  hf_chan  10  0 
-125.000000  db  (watts) 

17.514  MHz 
999999 

create_chan  hf_chan  11  0 
-130.000000  db  (watts) 

18.556  MHz 
999999 

create_chan  hf_chan  12  0 
-110.000000  db  (watts) 

20.025  MHz 
999999 

create  near_earth  1  0  NOSC 
1 

-117.27  32.70  0.0  0.000000 
logic_node  110 
transmitter  1110 
HF  1 

40.0  watts 
999999 

receiver  1110 
HF  1 

34,0  db  req  S/N 
-125.0  db  watt  noise 
999999 

scen_cont  1110 
0 

999999 

UNT_PrLayer2  1120 
0 
1 
1 

999999 

UNT_PrIjayer3  113  0 
0 
1 

999999 

999999 

999999 

create  near_earth  2  0  Point  Mugu 
1 

-119.12  34.12  0.0  0.000000 
logic_node  210 
transmitter  2110 
HP  1 

40.0  watts 


999999 

receiver  2110 
HF  1 

34.0  db  req  S/N 
-125.0  db  watt  noise 
999999 

scen_cont  2110 
0 

999999 

UNT_PrLayer2  2120 
0 
1 
1 

999999 

UNT_PrLayer3  2130 
0 
1 

999999 

999999 

999999 

create  near_earth  3  0  San  Clemente  Island 
1 

-118.57  33.03  0.0  0.000000 
logic_node  310 
transmitter  3110 
HF  1 

40.0  watts 
999999 

receiver  3110 
HF  1 

34.0  db  req  S/N 
-125.0  db  watt  noise 
999999 

scen_cont  3110 
0 

999999 

UNT_PrLayer2  3120 
0 
1 
1 

999999 

UNT_PrLayer3  3130 
0 
1 

999999 

999999 

999999 


137 


create  near_earth  4  0  San  Nicolas  Island 
1 

-119. S2  33.23  0.0  0.000000 
logic_node  410 
transmitter  4110 
HF  1 

40.0  watts 
999999 

receiver  4110 
HF  1 

34.0  db  req  S/N 
-125.0  db  watt  noise 
999999 

scen_cont  4110 
0 

999999 

UNT_PrLayer2  4120 
0 
1 
1 

999999 

UNT_PrLayer3  4130 
0 
1 

999999 

999999 

999999 

create  near_earth  5  0  Seal  Beach 
1 

-118.08  33.75  0.0  0.000000 
logic_node  510 
transmitter  5110 
HF  1 

40.0  watts 
999999 

receiver  5110 
HF  1 

34.0  db  req  S/N 
-125.0  db  watt  noise 
999999 

scen_cont  5110 
0 

999999 

UNT_PrIjayer2  5  12  0 
0 
1 
1 
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999999 

UNT_PrLiayer3  5  13  0 
0 
1 

999999 

999999 

999999 

create  near_earth  6  0  Ship 
1 

-117.84  32.88  0.0  0.000000 
logic_node  610 
transmitter  6110 
HF  1 

40 . 0  watts 
999999 

receiver  6110 
HF  1 

34.0  db  req  S/N 
-125.0  db  watt  noise 
999999 

scen_cont  6110 
0 

999999 

UNT_PrLayer2  6120 
0 
1 
1 

999999 

UNT_PrIjayer3  6  13  0 
0 
1 

999999 

999999 

999999 

create  near_earth  7  0  P3 
5 

-120.00  33.90  1.0  0.0000 
-118.00  33.00  1.0  2100.0 
-118.00  32.54  1.0  2640.0 
-120.00  32.54  1.0  4500.0 
-120.00  33.90  1.0  6000.0 
logic_node  710 
transmitter  7110 
HF  1 

40.0  watts 
999999 

receiver  7110 


HF  1 

34.0  db  req  S/N 
-125.0  db  watt  noise 
999999 

scen_cont  7110 
0 

999999 

UNT_PrLayer2  7120 
0 
1 
1 

999999 

UNT_PrLayer3  7130 
0 
1 

999999 

999999 

999999 

create_sys  system  0 

1500000.0  //simperiod  in  simulation  time  units 
259200.0  //report  update  period  in  simulation  time  units 
99.75000  //scenario  update  period  in  seconds 
0 
0 

999999 


Figure  68  Exan^Ie  of  61e  creaie.daL 

Figure  69  contains  an  exanqile  nfss.inp  file,  which  is  compatible  with  the  create.dat  file  shown  in 
figure  68.  In  rvder  to  be  compatible,  file  nfss.inp  must  have  the  same  number  of  frequency  entries  as  there 
are  diannels  in  cieate.dat,  ami  the  numbering  of  the  channels  in  create.dat  must  correspond  to  the  position 
of  die  corresponding  frequency  in  nfss.inp. 
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1.1 

10680.0 

11062.5 
12030.0 

12673.5 
13238.0 
13980.0 
14695.0 
16923.0 
16954.0 
17514.0 
18556.0  ■ 
20025.0 
-1.0 


Figure  69  Exunple  of  file  nfss-inp 


Other  Pre-Test  Preparations 
None. 

133J,  Additional  Tests 
TBD 


13.4  Formal  Qualifications  Test  Descriptions 

13.4.1  7-Node  Simulation  (7NFSE) 

A  7-node  simulation  model  will  be  used  to  test  the  NC  CSCI.  This  model  is  based  on  the  actual  7- 
node  HF  network  used  for  the  UNT/NRL  HF  Intratask  Force  Communication  Network  E^riment  This 
section  describes  the  different  test  cases  for  the  same  simulation  model. 

13.4.1.1  7-Node  Simulation  Test  1  (TNFSE-Tl) 

13.4.1.1.1  7-Node  Simulation  Test  1  Requirements  Traceability 

Die  purpose  of  this  experiment  is  to  verity  that  the  algoridims  of  the  NC  are  performing  properly 
in  an  environment  of  extremely  npdly  changing  channel  noise  levels.  We  show  that  the  algoriduns  behave 
as  expected.  However,  we  note  that  the  model  really  precludes  die  possibility  of  finding  a  “best”  frequency 
because  performance  at  every  frequency  is  rapidly  a^  continually  dianging  by  significant  amounts. 
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13.4.1.U  7>Node  Simulation  Test  1  Initialization 

The  NC  data  hies  described  in  Section  10. 1.6  are  used  for  this  test.  The  DSPT  input  hie  create.dat 
is  used  for  the  specihcation  of  the  simulation  model  along  with  the  HF  communication  channel  setup.  The 
NFSS  related  input  hie  nfss.inp  is  used  for  specihcation  of  the  test  frequencies.  The  initialization  data  and 
the  formats  are  ^scussed  in  Section  13.4.1.1.3 

The  DSPT  based  simulated  environment  is  created  using  the  input  hie  create.dat  This  hie  uses  a 
pre-specihed  format  for  the  description  of  the  7-node  model  and  the  HF  channels  for  the  communication 
network.  The  hie  format  is  described  in  the  above  referenced  documents.  The  HF  channel  specihcations. 
for  the  NFSE  test  channels,  are  discussed  in  Section  13.4. 1.1.3. 

13.4.1.U  7-Node  Simulation  Test  1  Inputs 

For  this  test  case,  we  use  the  set  of  12  frequencies  12161, 12162 .  12172  kHz,  which  corre¬ 

spond  to  chaimels  1  through  12,  respectively.  The  slightly  different  frequencies  are  used  for  identihcation 
purposes  only.  Each  channel  has  the  same  median  noise  level  of  -130  db.  Each  receiver  is  assumed  to  have 
a  receiver  noise  level  of  -  ISO  db.  All  platforms  are  assumed  to  be  stationary.  Other  input  parameters  are  as 
shown  in  hgure  68. 

The  noise  model  was  modihed  for  this  test  to  produce  a  sinusoidally  time-varying  about  the  con¬ 
stant  median  level.  The  amplitude  of  the  sinusoid  is  set  at  10%  of  the  median  noise  level.  All  channels 
share  the  same  time-varying  model.  The  channel  noise  levels  and  the  receiver  noise  levels  are  chosen  in 
such  a  way  that  the  channel  noise  dominates.  Thus,  performance  on  a  given  frequency  depends  on  when 
the  channel  is  tested. 

The  sinusoidal  time-period  for  the  charmel  noise  is  set  at  10  minutes.  The  duration  of  each  fre¬ 
quency  test  cycle  is  99,750  ms  « (Sepochs*  5  frames/epoch  +lepoch*10ftames/epoch)*  7siots/frame  * 
570ms/slot.  Based  on  a  10  minute  time  period  for  the  sinusoidal  noise  variation,  there  will  be  approxi¬ 
mately  6  such  test  cycles  in  one  sinusoid  time-period.  During  each  test  cycle,  three  new  frequencies  plus 
the  current  “best”  frequency  are  tested. 

13.4.1.1.4  7-Node  Simulation  Test  1  Expected  Results 

Figure  70  depicts  an  example  test  sequence  to  illustrate  the  expected  results.  For  illustration  pur¬ 
poses  we  assume  a  linear  noise  increase.  For  Test  Cycle  i  the  four  test  frequencies  are  evaluated  at  the  time 
instants  marked  1  through  4.  The  best  metric,  for  identical  receiver  noise  levels,  will  correspond  to  the  first 
frequency  (say  fl).  In  Test  Cycle  i+1,  the  best  frequency  carried  over  from  previous  cycle  will  be  fl.  The 
metric  evaluated  for  fl  in  Test  cycle  i+1  will  be,  in  general,  greater  than  the  one  from  Test  Cycle  i.  In  test 
Cycle  i+1  the  best  frequency  metric  will  correspond  to  time  instant5  (with  corresponding  frequency 
denoted  as  f5).  Thus  the  best  frequency,  for  monotonically  increasing  noise  levels  and  same  receiver  noise, 
will  be  the  first  test  frequency  during  each  test  cycle.  In  an  analogous  marmer,  for  decreasing  noise  case, 
the  best  frequency  will  always  be  the  last  test  frequency,  i.e.  the  best  frequency  from  the  previous  cycle. 
Thus  decreasing  noise  levels  will  always  result  in  a  the  selection  of  the  same  “best”  frequency  for  a  series 
of  test  cycles. 

Figure  71  qinimariTfts  the  expected  results  for  the  sinusoidal  noise  model.  Note  that  there  is  a 
fdiase  shift  in  the  sinusoid  since,  in  the  actual  tests,  the  first  NFSS  test  cycle  does  not  occur  until  79.8  sec¬ 
onds  into  the  simulation.  Figure  71  shows  the  expected  sequence  of  frequencies  tested  (and  therefore  the 
expected  sequence  of  best  frequencies,  as  well).  This  is  indcated  by  the  charmel  number  that  is  written  in 


each  frequency  test  cycle  for  the  given  sinusoidal  noise  model.  The  anticipated  channel  sequence  was  gen¬ 
erated  on  the  basis  of  the  discussion  in  the  previous  paragraph.  For  example,  for  increasing  noise  levels, 
the  first  test  frequency  in  each  test  cycle  is  expected  to  be  the  best  frequency.  In  an  analogous  manner,  for 
decreasing  noise  levels  the  best  frequency  corresponds  to  the  last  frequency.  Hence,  over  periods  of 
decreasing  noise,  the  same  frequency  is  always  selected  as  the  best  frequency. 


Figure  71  Anticipated  resuitt  for  Test  I  based  on  relative  noise  levels  of  the  tested 

chunels. 
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13.4.1.1^  7*Node  Simuladon  Test  1  Criteria  for  Evaluadiig  Results 

The  simulation  results  should  approximate  the  expected  results  discussed  in  section  13.4.1.1.4. 

13.4.1.1.6  7*Node  Simidation  Test  1  Procedure 

The  test  is  to  be  conducted  as  a  Sim-H-  simulation  running  on  a  Sun  workstation. 

13.4.1.1.7  7>Node  Simulation  Test  1  Assumptions  and  Constraints 

See  section  13.4.1.1.3. 

13.4.1.2  7-Ngde  Simulation  Test  2  (7NFSE*T2) 

This  test  case  uses  frequencies  that  were  allocated  for  the  UNT  test.  The  7-node  model  for  Test  2 
has  stationary  nodes.  The  noise  levels  for  the  HF  channels  are  constant 

13.4.1.2.1  7-Node  Simulation  Test  2  Requirements  TVaceability 

This  test  is  used  to  verify  the  operation  of  the  network  frequency  selection  algorithm  under  static 
conditions.  This  test  provides  a  general  test  case  and  serves  as  a  benchmark  for  comparing  different  met¬ 
rics. 

13.4.1.2J1  7-Node  Simulation  Test  2  Initialiatation 
See  Section  13.4.1.1.2. 

13.4.1.23  7-Node  Simulation  Test  2  Inputs 

As  described  in  Section  13.4.1.1.3,  the  NFSE  specific  test  inputs  are  the  test  frequency  channels 
along  with  their  associated  noise  levels.  Ihble  30  shows  the  different  frequencies,  their  associated  chaiuiel 
noise  levels,  and  the  corresponding  communication  ranges  used  for  this  test  case.  The  receiver  noise  is 
taken  to  be  -125  db.  All  platforms  are  assumed  to  be  stationary.  All  other  values  are  as  given  in  figure  68. 

Table  29:  Frequencies,  channel  nt^  levels,  and  communication  ranges  for  tests  7NFSE-T2. 


Freq.  Array 
Index 

Freq.(Khz) 

Channel 

Noise(db) 

Range* 

(Km) 

0 

10680.0 

-100.0 

37.97 

1 

11062J 

-115.0 

81.72 

2 

12030.0 

-135.0 

115.38 

3 

12673J 

-125.0 

10939 

4 

132383 

-110.0 

50.0 

5 

13980.0 

-125.0 

98.6 
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Table  29:  Frequencies,  channel  noise  levels,  and  communication  ranges  for  tests  7NFSE*T2. 


a.  Range  is  based  on  the  noise  at  the  receiver,  which  is  approx¬ 
imated  as  the  larger  of  the  channel  noise  (see  column  3)  and  the 
receiver  noise  (-125  db). 


13.4.1.2.4  7>Node  Simulation  Test  2  Expected  Results 

We  expect  that  the  channel  with  the  greatest  communication  range  will  be  selected  as  the  “best” 
frequency.  For  this  test  case,  with  12  test  frequencies,  which  are  tested  at  the  rate  of  3  new  frequencies  per 
test  cycle,  it  takes  4  Test  Cycles  (or  399  seconds)  to  complete  the  testing  of  all  frequencies.  Tl^after,  the 
results  of  tests  at  a  given  frequency  should  simply  repeat  the  earlier  results. 

13.4.1.2.5  7  Node  Simulation  Test  2  Criteria  for  Evaluating  Results 

Each  test  cycle  result  can  be  evaluated  individually  on  the  basis  of  the  frequencies  tested  and  their 
corresponding  HF  communication  ranges. 

13.4.1.2.6  7  Node  Simulation  Test  2  Procedure 
See  section  13.4.1.1.6. 

13.4.1.2.7  7  Node  Simulation  Test  2  Assumptions  and  Constraints 
See  section  13.4.1.2.3. 

13.4.1.3  7-Node  Simulation  Test  3  (7NFSE-T3) 

This  test  case  uses  the  same  setup  at  7NFSE-T2  (See  section  13.4.1.2)-  the  only  (hfference  being 
that  it  uses  a  dynamic,  7-  node  model,  i.e.,  during  the  simulation  run  one  of  the  nodes  traverses  a  pre¬ 
defined  path  through  the  remaining  nodes. 
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13.4.1.3.1  7>Node  Simulation  Test  3  Requirements  IlTaceability 


This  test  verifies  the  network  frequency  selection  algorithm  under  changing  connectivities 
induced  by  the  physical  model  dynamics.  The  noise  levels  ior  the  HF  channels  are  still  kept  constant,  with 
the  values  shown  in  table  30. 

13.4.1.3J  7>Node  Simulation  Test  3  Initialization 
See  section  1?  4.1, 1.2. 

13.4.1.33  7*Node  Simulation  Test  3  Inputs 

Table  30  shows  the  different  frequencies  and  their  associated  channel  noise  levels  used  for  this  test 

case. 

Table  30:  Frequencies,  channel  noise  levels,  and  communication  ranges  for  tests  7NFSE>T3. 


Freq.  Array 
Index 

Freq.  (Khz) 

Channel 

Noise(db) 

Range^ 

(Km) 

0 

10680.0 

-100.0 

37.97 

1 

11062J 

-115.0 

81.72 

2 

12030.0 

-135.0 

115.38 

3 

12673J 

-125.0 

109.59 

4 

13238.5 

-110.0 

50.0 

5 

13980.0 

-125.0 

98.6 

6 

14695.0 

-105.0 

36.6 

7 

16923.0 

-135.0 

77.35 

8 

16954.0 

-120.0 

60.35 

9 

17514.0 

-125.0 

73.57 

10 

18556.0 

-130.0 

67.22 

11 

20025.0 

-110.0 

29.75 

a.  Range  is  based  on  the  noise  at  the  receiver,  which  is  a]q)rox- 
imated  as  the  larger  of  the  channel  noise  (see  column  3)  and  the 
receiver  noise  (-125  db). 


13.4.13.4  7>Node  Simulation  Test  3  Expected  Results 
See  section  13.4.1.2.4. 
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13.4.13^  7  Node  Simulation  Test  3  Criteria  for  Evaluating  Results 
See  secdoo  13.4.1.2.5. 

13.4.1.3.6  7  Node  Simulation  Test  3  Procedure 
See  section  13.4.1.1.6. 

13.4.13.7  7  Node  Simulation  Test  3  Assumptions  and  Constraints 

See  section  13.4.1.2.3. 

13.4.1.4  Otiier  Tests 
TBD 

13.5  Notes 

None. 

13.6  Revisions  to  Section  13 

None. 
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14.  NFSE  IN-LAB  TEST  REPORTS 

14.1  Section  Overview 

This  section  contains  the  test  results  of  formal  qualification  testing  of  the  NC  CSCI  of  the  NFSE 
System.  During  these  tests  we  were  particularly  interested  in  testing  the  network  frequency  selection  algo¬ 
rithm. 

14.2  Referenced  Documents 

See  references  [3]  and  [4]. 

14.3  Test  Overview 

14.3.1  7*Node  Simulation  (7NFSE)  Test  Overview 

14.3.1.1  7-Node  Simulation  Summary 

The  7-node  simulation  model  is  derived  from  tte  acmal  7-node  HF  Network  used  for  the  UNT/ 
NRL  HF  Intratask  force  communication  network  experiment  The  system  initialization  and  control  param¬ 
eters  were  set  on  the  basis  of  that  network.  Three  different  tests  were  performed  for  verifying  and  validat¬ 
ing  the  network  frequency  selection  scheme.  On  the  basis  of  the  input  parameter  settings  and  the  expected 
heuristic  system  behavior,  the  results  were  carefully  analyzed  and  the  correctness  of  the  results  were 
checked.  Based  on  the  results  obtained,  minor  improvements  in  the  metric  definition/selection  were  made 
(see  section  10.3.8.1. 

14.3.1.2  7-Node  Simulation  Record 

The  in-lab  tests  were  performed  at  the  Naval  Research  Laboratory,  Washington  DC,  in  July  1993. 

14.4  Test  Results 

14.4.1  7-Node  Simulation  (7NFSE)  Results 

14.4.1.1  7-Node  Simulation  Test  1  Results 

Figures  72  through  74  present  the  results  of  the  first  12  NFSS  test  cycles  of  a  simulation  run.  The 
7NFSE-T1  test  was  performed  using  a  sinusoidal  noise  model,  with  a  time-period  of  10  minutes.  As  each 
NFSS  test  cycle  duration  is  99.75  seconds,  a  single  noise  cycle  corresponds  to  approximately  6  NFSS  test 
cycles.  The  individual  fi^quency  tests  (total  4)  in  each  NFSS  test  cycle  are  presented  verticaJly  with  two 
NFSS  test  cycles  per  figure.  Hence  figures  72  through  74  represent  results  for  two  noise  cycles.  Eadt  panel 
has  an  identifier  that  is  coded  as  XX.  Y,  where  XX  is  the  NFSS  test  cycle  number  and  Y  is  the  frequency 
test  cycle  within  a  given  NFSS  test  cycle.  Simulation  time  {9)pears  as  hours:min:sec.ms  in  eadi  panel.  The 
remaining  items  in  eadi  pand  are  self-ex{danatory.  Hre  results  presented  ate  for  the  case  with  diannel 
noise  set  to  -130  db  with  a  10%  sinusoidal  variation.  Since  the  receiver  noise  was  kqrt  constant  at  -ISO  db, 
this  provided  a  receiver-noise  independent  NFSE  testing  setup. 
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Test  1  results  shown  in  figures  72  through  74  differ  slightly  from  the  expected  connectivity-range- 
based  results  shown  in  figure  71.  The  actual  results  show  the  sequence  (1. 2.  3. 1),  (4. 5, 6, 1),  (7. 8. 9, 1). 

(10, 11. 12. 7).{1.2. 3. 10).  (4,5.6, 3) . The  numbers  in  bold  face  indicate  where  the  anticipated  results 

differ  from  the  simulation  results.  On  closer  inspection  of  tte  results,  the  deviation  can  be  attributed  to  the 
way  Metric  A  resolves  ties  between  topologies  that  have  the  same  number  of  disconnected  nodes  and  the 
same  number  of  relay  nodes.  The  initial  metric  (referred  to  as  Metric  A)  resolves  ties  in  favor  of  the  fre¬ 
quency  with  the  lower  frequency  (channel)  index.  Hence,  in  the  second  NFSS  lest  cycle  (Nfss  tests  2. 1 
through  2.4.  which  appear  in  figure  72).  each  frequency  that  was  tested  required  one  relay  node.  However, 
frequency  channel  1  (12. 161  MHz)  was  selected  because  it  had  the  lowest  index  (0)  in  the  frequency  ublc. 
although  other  frequencies  clearly  provided  more  links.  Similar  results  occur  in  NFSS  tests  5. 1  through 
5.4. 


In  order  to  the  overall  network  connectivity  imo  account,  the  NFSS  was  tested  using  a  new 
metric  (referred  to  as  Metric  B,  and  defined  in  section  10.3.8.1),  which  refines  the  frequency  selection  pio- 
cess  to  also  consider  the  number  of  links  in  the  network.  Figures  75  through  77  show  the  results  for  Metric 
B.  Here  the  resulting  frequency  selectioo  sequence  docs  mtoch  the  expected  sequence  shown  in  figure  71. 
Subsequent  tests  were  all  performed  using  Metric  B. 


ISO 


^  a 


Nfss  Test  1.1;  Metric=0x40 

Nfss  Test  2.1;  Metrics=0x43 

12.1610Mh2;  (0:01:19.800) 

12.1640Mhz;  (0:02:59.550) 

A  2 

Nfss  Test  1.2;  Metric=0x41 

Nfss  Test  2.2;  Metric=0x44 

12.1620Mh2;  (0:01:39.750) 

12.1650Mh2;  (0:03:19.500) 

^  2 

^  2 

Nfss  Test  1.3;  Metric=0x42 

Nfss  Test  2.3;  Metric=0x45 

12.1630Mhz;  (0:01:59.700) 

12.1660Mhz;  (0:03:39.450) 

Nfss  Test  2.4;  Metric=0x40 
12.1610Mh2;  (0:03:59.400) 


Nfss  Test  1.4;  Metric=0x40 
12.1610Mhz;  (0:02:19.650) 


Nfss  Test  3.1;  Metric=0x86 
12.1670Mhz;  (0:04:39.300) 


7 

O 


o2 


Nfss  Test  4.2;  Metric=0x204a 
12.1710Mhz;  (0:06:39.000) 


1 

o 

o2 

4° 

Nfss  Test  4.3;  Mctric=0x204b 
12.1720Mhz;  (0:06:58.950) 

7 

O 

02 

4° 

Nfss  Test  4.4;  Metric=0x2046 
12.1670Mhz;  (0:07:18.900) 

(Snc  A)  Resulu:  Set  1 


Nfss  Test  5.1;  Metric=0x2040 
12.1610Mhz;  (0:07:58.800) 


Nfss  Test  5.2;  Metric=0x2041 
12.1620Mhz;  (0:08:18.750) 


Nfss  Test  5.3;  Metric=0xl02 
12.1630Mhz;  (0:08:38.700) 


Nfss  Test  6.1;  Metric=0xc3 
12.1640Mhz;  (0:09:38.550) 


Nfss  Test  6.2;  Metric=0x84 
12.1650Mhz;  (0:09:58.500) 


Nfss  Test  6.4;  Metrics0x82 
12.1630Mhz;  (0:10:38.400) 


igure  74  Test  1  (mnne 
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L 


Nfss  Test  1.1;  Metric=Ox  10100 
12.1610Mhz:  (0:01:19.800) 


Nfss  Test  1.2;  Metric=0x  10101 
12.1620Mhz:  (0:01:39.750) 


Nfss  Test  1.3;  Metric=0xl0102 
12.1630Mhz;  (0:01:59.700) 


Nfss  Test  1.4;  Metric=0xl0100 
12.1610Mhz:  (0:02:19.650) 


Nfss  Test  2.1;  Metric=0xl0103 
12.1640Mhz;  (0:02:59.550) 


1 


Nfss  Test  2.2;  Metric=0xl0104 
12.1650Mhz;  (0:03:19.500) 


Nfss  Test  2.3;  Metric=0x  10105 
12.1660Mhz;  (0:03:39.450) 


Nfss  Test  2.4;  Metric=0xl0180 
12.1610Mhz;  (0:03:59.400) 


TMgiSeTTTSrrTnSmc'ByReiulBr^etTr 


1S4 


^2 

2 

\  f 

V--./ 

r<^i 

Nfss  Test  3.1;  Metiic=0x20206 

Nfss  Test  4. 1 ;  Metric=0x403c9 

12.1670Mhz;  (0:04:39.300) 

12.1700Mhz;  (0:06:19.050) 

7  0^ 

\  l\l{ 

° 

v^\/\ 

4° 

3 

6^^^1 

Nfss  Test  3.2;  Metric=0x20287 

Nfss  Test  4.2;  Metric=0x8104ca 

12.1680Mhz;  (0:04:59.250) 

12.1710Mhz;  (0:06:39.000) 

7 

\ 

0  5 

y^_/\ 

4° 

3 

3 

6\q1 

Nfss  Test  3.3:  Metric=0x30308 

Nfss  Test  4.3;  Metric=Ox8104cb 

12.1690Mhz:  (0:05:19.200) 

12.1720Mhz;  (0:06:58.950) 

7 

\ 

v^^/\ 

4° 

3 

3 

Nfss  Test  3.4;  Metric=0x30303 

Nfss  Test  4.4;  Metrics0x8104c6 

12.1640Mhz;  (0:05:39.150) 

12.1670Mhz;  (0:07:18.900) 

'igure  76  Test  1  (metnc  B)  Resulti:  Set 
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Nfss  Test  5.1;  Metric=0x8104c0 
12.1610Mhz;  (O;0r7;58.8(X)) 


Nfss  Test  6.1;  Metric=0x30303 
12.1640Mhz;  (0:09:38.550) 


Nfss  Test  5.2;  Metric=0x8104cl 
12.1620Mhz;  (0:08:18.750) 


Nfss  Test  6.2;  Metric=0x20284 
12.1650Mhz;  (0:09:58.500) 
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14.4.1.2  7  Node  Simulation  Test  2  results 

As  mentioned  in  section  1 3.4. 1 .2.4,  we  expect  that,  for  this  example,  the  best  frequency  will  be  the 
one  with  the  greatest  communication  range.  For  Test  2.  the  frequencies  and  communication  ranges  are 
shown  in  table  30.  Figures  78  and  80  show  Test  2  results  for  24  frequency  test  cycles  (more  than  enough  to 
cycle  through  the  entire  set  of  frequencies).  As  expeaed  the  best  metric  corresponds  to  test  frequency 
10.31  Mhz  with  an  associated  communication  range  of  132  km.  The  best  frequency  for  NF^S  test  cycles  1. 
2  and  3  is  12.03  Mhz  (with  range  1 15  kms),  but  for  NFSS  test  cycle  4  the  best  frequency  is  updated  to  its 
final  value  of  10.315  Mhz. 


Ftfnrc  78 IM  2(iDe«nc  B)  Resma:  Set  1 


Nfss  Test  3.1;  Metric=0xc00546 
14.6950Mh2;  (0:04:39.300) 


Nfss  Test  4.1;  Metrics=0x8104c9 
17.5140Mhz;  (0:06:19.050) 


Nfss  Test  3.2;  Metric=0x8104c7 
16.9230Mh2;  (0:04:59.250) 


Nfss  Test  4.2;  Metric=0x2028a 
10.3150Mhz;  (0:06:39.000) 


Nfss  Test  3.3;  Metric=0xa(X)508 
16.9540Mhz;  (0:05:19.200) 


Nfss  Test  4.3;  Metric=0x3030b 
8.57800Mhz;  (0:06:58.950) 


Nfss  Test  3.4;  Metric==Qx30302 
12.0300Mhz;  (0:05:39.150) 


Nfss  Test  4.4;  Metric=0x30302 
12.0300Mhz:  (0K)7: 18.900) 


1S9 


Rgure  80  Test  2(metnc  B )  Ke^ts:  Set  3 
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14.4.1.3  7  Node  Simulation  Test  3  results 


The  7NFSE-T3  test  incorporates  a  model  with  one  mobile  node.  Platform  7  was  a  simulated  as  a 
dynamic  node,  which  traversed  a  pre-specihed.  deterministic  path  through  the  remaining  nodes.  This 
allowed  for  a  realistic  representation  of  an  actual  HF  network  and  demonstrates  the  effects  of  platform 
motion  on  the  frequency  selection  process.  The  results  are  shown  in  figures  81  through  86.  As  predicted  in 
section  13.4.1.3.4,  after  all  frequencies  have  been  tested,  the  best  frequency  corresponds  to  the  channel 
with  the  greatest  communication  range.  For  Test  3.  channel  3.  with  frequency  12.03  MHz.  has  the  greatest 
communication  range  (115  km).  The  results  show  that  this  frequency  is  eventually  chosen  as  the  btSL  fre¬ 
quency.  The  results  also  illustrate  how  the  values  of  the  metric  change  as  platform  7  moves.  For  example, 
at  the  frequency  12.03  MHz  the  metric  changes  from  0x30302  to  0x302c2  to  0x30282  to  0x20242  as  ^at- 
form  7  moves  into  positions  where  more  links  are  formed. 
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Figure  82  Test  3  (metric  B)  Resultr  Set  2 
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Figure  S3  THt  3  (metnc  B)  Results:  Set  3 
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higure  K»  Test  3  (metnc  B)  Resulu:  set i 
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Rgm  86  Test  3  (metric  B)  Routt:  Seto 
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